Sunday, December 12, 2010

"Where does the QA fit into Scrum" - common suboptimal implementation of Scrum

Here is quite common and very suboptimal implementation of scrum ("Where does the QA fit into Agile"). I have seen this multiple times in the context of multivendor projects where "testing" is externalized to one company and development for yet another company.

I commented the post in the following way:

Sorry to say but this is common suboptimal "implementation of scrum", some refer it "scrumfall" and some think that it is not scrum at all. You simply get feedback "an iteration too late" and your software is never done when "exiting the development phase". Smell of this implementation is usually definition of done saying "ready to be tested".

Anyway, here is how to make it better:
  • Form a cross-funtional team with developers AND testers in it - their definition of done is "releasable product/project increment" that is tested
  • There might not be sense to have analysis as "iteration", analysis is continuous flow

How does the tester then participate in the development sprint to get the items you highlighted done:
  • New feature testing
    • In sprint planning the testers will help the team to figure out the acceptance criteria for the incoming feature. They might even express that as executable acceptance test (see: http://www.slideshare.net/tcmak/atdd-in-practice) or they might do that within the sprint.
    • During the sprint testers are doing exploratory testing to find the corner cases of the feature and "how it fits to the whole".
    • In the demonstration testers help the product owner to see that the acceptance criterias pass and they are there also to make sure that if something is not done then it won't be demoed
  • Feature integration testing
    • Integration in the large: testers may work on emulating the external systems or testing these cases (by automating the regression suite)
  • Regression testing
    • This is the "product" that testers will do step by step by automating the acceptance tests
It might sound that testers need to be developers. The testing is collaborative activity taken by the "team". If testers need something to be developed then the developers will develop that. Pairing helps a lot in here. Sometimes testers even help the developers to do unit testing because a tester has different point of view which is usually very beneficial.

Many teams (including ours) have successfully managed to build security and performance testing suite that can be executed part of the continuous integration/deployment and have also continuous monitoring in place (to improve these suites). Still there is testing (usability comes into my mind) that might be very hard to fit into sprints .. even by taking 1 small piece in the time.

Edit: Ron Jeffries has also written reply on his blog.

Friday, December 10, 2010

Single product owner model is broken. Problem and Solution team to the rescue?


It is more important to build the right thing than build the thing right. That's why this is important.

This post is based on personal experiences and the feedback that I've gotten from hundreds of individuals I've been working with: "Product owner (PO) model seems to be broken", "PO is a superman, nobody can do that", "single PO is bad idea" etc.

The motivations to write this is are: 1) find better models 2) provoke you to share about your experiences 3) provoke the community to challenge existing models 4) Books and courses about product ownership seem to concentrate on backlog management and scrum. I find that secondary to figuring out what should be done and when 5) .. finally describe the problem to some people asking me about "why do you think single product owner model is broken" in twitter. (@rowanb @hkokko @romanpichler @toolsforagile ...) :o)

What is a product owner by definition and how it is broken:

1. "the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does"
We together as organization are here to max value. It should not be only PO's responsibility though it might be a good idea to have one person looking after that value constantly. Team should challenge the value proposition that PO is stating in order to improve it. Team should be driven by the goal(s) to maximize the value instead of externalizing it to PO role.

2. ".. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece ..."

This underlines the PO bottleneck problem. They are not truly POs requirements but stakeholders'/customer's requirements that are flowing trough a PO proxy. It is a bad idea to form such a bottleneck for information flow. In addition I would not like to have "one hearsay" talking about what the customer wants.

The guide and CSM courses have notion that ScrumMaster can teach PO. That's just naive - Most of the certified scrum masters/practitioners that I know have zero knowledge how to study the demand from the customer to understand how the value could be maximized. They often do know how to do backlog management.. but that is typing exercise once you know what needs to be build. Very few ScrumMasters know anything about customer development, business model generation, feature injection, defining MVP etc.

What makes this even worse is that organizations "promote" their POs from "ex-QA guy" or "ex-project manager" who has not been working with these kind of tools. CSPO (certified product owner) does not help here either - you get to hear about storymaps/product visioning, but it is not a product management/business analysis training (I am not saying it even should be).

3. "The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the Team performs."

Yes, we need one being eventually accountable might be the PO or might not.

Ensuring value is just a joke. Customer and your market will tell if you are producing value and you should not give that as "responsibility" to single person in your organization. I rather have transparency to the realized value all the time and want my people to think how to improve on it. For most of the organization "definition of done" ends to "stuff released" and they might be happy about their velocity ("we are so productive") but that all is meaningless as long as you do not measure the realized value and act on it (for instance by removing not used/invaluable features).

For project organization that works on subcontracting "stuff released" though might be "good enough" - if your contracts are not aligned with customer's goals (realized value).

4. "For commercial development, the Product Owner may be the product manager."
Not such a good idea. Here is a slide deck explaining the difference of there roles. One practical issue is that product managers are so busy on figuring out the problem to be solved that they won't be there to support the team (as PO role is defined)

5. "Committees may exist that advise or influence this person, but people who want to change an item’s priority have to convince the Product Owner."
So there we have it, we should have a team to help the PO.

PO is a collaborator for the team ... which is good ... but shouldn't he be studying and developing customers? Smell of contradicting priorities - who to serve and when. I do not want to have this bottleneck.

6. "The Product Owner identifies what has been done and what hasn’t been done."

Why? Why don't we have agree definitions and better transparency - we should all know when it is done and we all are working for the same goal.

On practical side of the things: we do not demonstrate the results of our work for our CEO (who could be the product owner) as we found that to be bottleneck for getting the stuff out. This of course requires that we have very good understanding of the goals and we have evolved our "Definition of Ready and Done" into something that our CEO can trust.

If you are subcontractor you might want to have the "demo acceptance" by "a customer representative". Context.

7. "The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization."

This leads to waiting as items are not available / good enough to be developed. The people doing the work are best to estimate when something is good enough to be developed - POs usually do not have that skill and if they are more than "backlog management PO proxies" they wont have the time to do this.

8. "The Product Owner keeps an updated Product Backlog list Release Backlog Burndown posted at all times."

Anyone can do this, it is about .. big word .. trust.

Context

You might find my angle weird. Take a look at this slide and ask yourself which product owner role you have in your organization. I am talking about big Ps preferably in goal driven context.

Alternative: Problem and Solution team

"All models are broken, but some are useful". Some are even more useful than others so here is model that I think works better than single PO model. Some might find this model familiar since it is mentioned several times in various #leanstartup sessions.

I start by sharing two diagrams: 1) customer development as a parallel process to product development. You might not be doing customer development but you are doing "something to figure out what should be done" - consider that as your parallel process.


Second diagram to demonstrate how the problem and solution teams are working on these processes:

The teams are working simultaneously, exchanging hypotheses, findings, problems and solutions.

Problem team

The goal of the problem team is to find out and define the problem to be solved. This team is all about "what".

Members:
- Sales
- Marketing
- Executive(s) (accountability)
- Technology
- Usability
- Quality (testing, QA/QC whatnot)
- Support

Solution team

The goal of the solution team is to figure out best possible way to solve the defined problem. This team is all about "how".

Members:
- Cross-functional development team including:
- Same technology representative who is in Problem team
- Same quality representative who is in Problem team
- Same usability representative who is in Problem team

Collaboration (overlapping)

Both teams try together to maximize the value. Problem team is trying to achieve this by figuring out who is the customer and what is a problem that is worth of solving. Solution team is providing transparency to the market feedback .. usually in form of solution based statistics.

.. within a context

Startup

In startup the teams may overlap heavily - it may be that the team members for both teams are the same.

Enterprise

In enterprise the teams may exist for each product line / project and the overlap might be restricted to only few team members.

Benefits compared to single product owner model

According to my experience problem-solution team model (compared to single product owner model) provides:
  • Improved information and knowledge sharing about the problem and the solution
  • Better alignment towards the goal and shared responsibility about value creation
  • Multiple views on customer's needs (for instance not only product vision but also architecture and usability vision)
  • Channel for constructive feedback (in a form of feedback loop from the solution team)
  • Multiple communication points avoiding the issue of "PO knows it all as he is only one talking to the customer"
  • Focus on shared team vision and discipline instead of "individuals and interactions"
Things to consider
  • If you are in a context where you just "execute the big-upfront-planned-requirements" .. you just need "requirements management"
  • If you need firewall for the team from several stakeholders then you might prefer single product owner model (or proxy between solution/problem teams)
  • Contracting model (in subcontracting) may prefer single product owner model
  • Maybe you do not need either models. You might have working model and your product managers in place with their MBAs - beware dogma - product ownership is a function to be carried out not a role :o)

Real life examples

Energized work product stream
Huitale's problem-solution team


Photo credit: Darwin Bell @ flickr