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: 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.


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".

- 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".

- 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


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


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

Sunday, May 16, 2010

Agile Saturday Presentation: "8 Lessons Learned from Becoming Agile"

Here are the video and the slides for a presentation I gave on 15th of May at Agile Saturday organized by Agile Estonia.




1.Why do you want to be agile?
L1: Set a goal for being agile or you achieve nothing
L2: Commit to agile values and principles; your practices will follow
L3: Pilot is about learning. Learning is progress.

2.How to reach business agility?
L4: Business agility is about having adaptability and predictability
L5: Create product vision and validate it with customer development
L6: Find your Minimum Viable Product

3.Organization as a people system
L7:Optimize the whole
L8: Build great teams

Community notes

The books I mentioned

The Four steps to Epiphany (Customer development, twitter hashtags #custdev and #leanstartup):

The Five Dysfuntions of a Team (must read for team leads / scrum masters / managers): Estonian translation: (cover picture):

Thanks to Erkki Kildvee for sending the cover picture :o)

Tuesday, May 4, 2010

Scrum Guide in Finnish

I and Samuli from Huitale are proud about participating to the translation. The first version of Finnish translation of the Scrum Guide is now available at

Thanks to other participants: Arto Eskelinen, Petri Heiramo, Antti Järvinen, Lasse Koskela, Lare Lekman, Pentti Virtanen, Vesa Vänskä ja Lasse Ziegler.

Agile Finland will take the ownership from now on so if contact the association if you want to contribute.

More information about the translation (in Finnish):

Monday, May 3, 2010

Commenting Iterations versus Continuous flow

I thought to share a comment I posted to very interesting blog post by @dennisstevens.

I asked few question from Dennis in twitter already but then I thought sharing and elaborating them here.

I am a co-founder & CTO in a startup that practices continuous flow in product development, though we used to practice time-boxed iterations. If you care to read how we changed our process just take a look at:

And our current way with total value stream:

In twitter I challenged the point "Continuous flow makes most sense when the outcome is pretty clear and feedback is not as likely to impact subsequent work". For us it has been the opposite. It made sense to drop time-boxes to enhance the feedback cycle (one piece flow, faster cycle time, faster feedback from the market).

Eric Ries has defined A startup as "a human institution designed to deliver a product or service in conditions of extreme uncertainty" so it is has nothing to do with the size of the company, the sector of the economy or the industry the business is involved in. For me it means two things in this context: 1) there is no stable product 2) feedback from your internal iterations is less valuable than iterations that you do together with the customer (customer development is the thing that we talk in lean startups). Therefore getting stuff out faster (continuous flow instead waiting for the time-box to end) gets you the feedback faster.

Under these circumstances we practice continuous flow and it seems that our findings seem to contradict the claim that "time-boxed iterations work best at the outset with a new product, new technology, or substantially new set of features.". If I would have written similar blog entry, I would have told the opposite and that made me wondering is it just me :o)

I also happen to consult companies with agile & lean and usually help them start with iterative time-boxes. Why? Because time-box gives a boundary in their chaotic environment. Starting with continuous flow would be too hard as they do not know their WIP nor their value stream(s) and figuring out those will take some time.

So my conclusion would be:

Iterative time-boxed approach makes most sense when you have chaos and you need to establish a boundary to get something done.

Otherwise prefer continous flow.

Wednesday, March 31, 2010

How to allocate time for bug fixes in agile?

Recently I have been discussing with various people about bug fixing and getting high quality software. as part of that I happened to comment a blog entry about incentive driven bug fixing activity called "Bug Week" and thought it to be bad practice due to Deming's points about incentives and the personal experience I have for developing software and managing the development of software. The discussion went even further.. I might address the "objective of zero defects" later as it is a whole different topic addressed by lots of people.

Nate however asked very common question that I have heard from various agile teams:

"How to allocate time for bug fixes in sprints while continuing to add new capabilities to the product."

I have multiple non-incentive driven solutions that I have tried with various teams:

1. The Huitale Way - Drop sprints, Stop-and-Fix

As you might know, we in Huitale practice stop-and-fix as our bug fixing practice.

2. Allocate X% of your velocity for bug fixing and other maintenance tasks

If you need to support an existing version of the product while you are sprinting it is a good idea to allocate time for support/unplanned work/maintenance/bug fixing in all your sprints.

3. Bugs as backlog items

Fixing bug must be valuable. Why not to estimate that business value and prioritize the bugs as items in your product backlog? Some bugs might even not be worth of fixing.

4. Have limit for bugs

Some teams have set a limit for bugs. They try to keep number of known issues less than that limit. When the limit is about to be exceeded by a new bug they will start fixing some bug immediately to make room for the new bug.

5. If you are running Kanban, have a swimlane/SLA/Urgent slot for urgent work

Community members have already described urgent slot, swimlanes, and SLAs so I won't do it here.

In the end of the day it is about everyone taking responsibility and being responsible about the product. If you do not have that, no incentive, set objective or practice will help.

Tuesday, March 23, 2010

The Huitale Way - Our Value Stream Map

I previously blogged about The Huitale Way and How we release our product every day. The comments on those encouraged me to share our simplified value stream map with the community. My motivation? 1) get feedback in order to improve and 2) give you some ideas. Here it goes:

The stated cycle times (in green) are averages that we measure and keep updated. Orange icons are the buffers in our system to ensure smooth flow and to have independent cadences for business to figure out WHAT we should build and development to BUILD it. Please keep in mind that all our developers are part timers (we do agile and lean consulting besides the development).

MMF stands for a Minimum Marketable Feature that is the smallest possible set of functionality that, by itself, has value in the marketplace. Read more about MMFs from Karl's blog.

DWT stands for Disneyland Wait Time. It is the expected wait time to get full backlog (7 MMF s) DONE, which is good information for our Product Owner.

Discovering themes

Our product development has several inputs:
  • we try to meet users (Finnish) in a brainstorming session every month in our office
  • we have done feature voting, surveys and get-together with our community
  • we try to engage discussions with our users via Facebook group, monthly newsletter (Finnish) and Twitter
  • we are lucky enough to get feedback from our users via email
  • we dig into our metrics and business reports (AARRR etc.) to figure our what works (we also look for features that are just waste)
  • we look into competition and new partnerships
  • we try to come up with new bright ideas for our product
I think we are still learning and improving our ways to do customer development... Anyway, from these inputs we formulate common themes. Once we have the themes formulated we select up to three themes (WIP limit 3) that we should work on next. The selection is based on what direction we want to take as a company. Naturally we can come back to these themes at any given time to steer the product development according our company objectives - in the end of the day product development exists for the business :o)

Figuring out the Minimum Marketable Features (MMFs)

Once the themes are selected, we work on those until we have MMFs to serve the theme in best possible way. We argue the business value of each MMF and figure out the T-shirt size of each MMF (have been thinking of using Story Maps, Kano model etc. here. So far it has been just list of MMFs each having relative value that is based on our business value model, this is definitely an area that we sould also improve) and finally our Product owner chooses up to seven items to "product backlog" (WIP limit 7), which is actually just queue of NOT-STARTED MMFs, not necessarily in prioritized order as real product backlog would be. Why you might ask.. because developers cannot pull items from there as they are not READY yet.

From NOT-STARTED to DONE aka when are we READY and when are we DONE?

Product owner prioritizes the MMFs and starts working together with the team to get top items READY.

So what's our definition for READY?
  • No immediate blocker for developing the MMF
  • If MMF has impact on language content the content is available. It might not be final.
  • If MMF has impact on look & feel the content is available (GUI layouts, graphics..). It might not be final.
  • If MMF has impact on emails sent to the users the email templates are available. They might not be final.
  • If MMF has impact on reports the expected changes are communicated.
  • If MMF has impact on third party services/integrations the expected changes are listed. List might (and usually is not) final.
Once the MMF is ready it can be pulled to development. We have WIP limit of 2 for development items in order to keep the cycle time as short as possible. Currently our average development time for a MMF is 6 days.

What does it mean that MMF is DONE according our definition of DONE?
  • MMF can be released
  • code has unit tests and automated acceptance tests that execute successfully
  • code passes tests in CI environment
  • code is refactored and the design is simple
  • code passes automated QA checks (checkstyle, pmd/cpd & whatnot)
  • new feature is documented (if applicable, sometimes for third parties)
  • peer review is done (if applicable, sometimes for critical paths)
What if there is a bug? We stop the line (no MMF moves from a column to another column) and we work on the bug instead until it is DONE. We tried of having separate swimlane for bugs/ ad-hoc tasks, but then we noticed that we do not really need it.

Our current Kanban board

The bright blue boxes (SMART goals etc.) are kind of rules that we have for items that belong to a column.

You might be wondering how we divide the labor between "biz and tech". The following illustration demonstrates our Problem and Solution "teams":

They are heavily overlapping due that we are doing tons of collaboration in each process step.

Have an idea to share? Please also comment for suggesting a topic for next post - I was thinking of showing what exactly is our MMF (internals) or maybe how we work on GUI as it seems to be hot topic in agile community right now.

Friday, March 19, 2010

Turku Agile Day 2010 Presentation: "How to sell agile to my manager?"

Here are the slides for a presentation I gave on 18th of March at Turku Agile Day 2010.

How to sell agile to my manager?
View more presentations from Marko Taipale.


In order to sell anything you need to 1) Know your product 2) Know your customer 3) Understand her need.

Knowing our product is hard as it involves software development practices, values, principles, people skills. In addition one should understand the limitations of the product and alternatives for the product (competition).

Traditionally sales is about making value proposition. Value proposition consists of financial benefit (how much money you can save or generate with the product), functional benefit (time-to-market, quality, predictability, embracing business changes) and emotional benefit (happiness, well-being, sustainability.. team/customer/organization level).

If you list all the possible benefits that one could get from agile and you get it sold (or a consultant gets it sold) you should be really worried. Agility as such should not be the goal, but any organization adopting agile should consider why they want to be agile.

Pilots fail cause the management expectations are wrong and you seldom get truly cross-functional team working for the pilot. Pilots are about learning not about getting all the possible benefits that agile could bring. Make sure your management understands that building the knowledge should be the goal for your first agile pilot. Organization should be really interested looking into impediments that will surface once the pilot is kicked off.

Find out what is the current problem in your organization and see if agile could help there. Do not be dogmatic, sometimes agile is not the answer. If your organization is about to adopt agile make sure that you understand the goal and that it is SMART goal.

Turku Agile Day 2010 Retrospective

I participated to Turku Agile Day 2010 and thought about sharing my insights about the conference.

What went well
  • Organizers were helpful and you could feel their excitement. Thanks.
  • There was some buzz. That's a good sign.
  • 6 presentations talked about goals from different angles - having a goal is truly important (as is having a method)!
  • Presentations were good. Too bad I missed the Kanban talk while having my own session. Luckily got a chance to share ideas with Joakim later on :o)
  • Socializing events were excellent.
What to improve and how
  • Awareness room was way too big - hard to get "connected" with the speaker. Get a smaller room.
  • I (as a presenter) want some feedback - People should tweet more, be proactive :o). I hope hearing some feedback from the organizers in order to improve.
  • I felt that the presentations did not necessarily met the majority of the audience (some individuals yes..).
Other thoughts
  • Pascal's & Portia's keynote got people involved. Need to think about applying some of their presentation methods :o)
  • Vasco's session was very good and I enjoyed it a lot. I personally would have taken the path from business to R&D instead starting from R&D and kind of leveraging it to business - even the cases are "bottom-up". R&D is there for the business so presenting that direction might help the audience to grok the presented ideas.
  • Petri Heiramo's talk was about training the customer. Once again solid and well articulated presentation from Petri. It would have been interesting to share ideas how to overcome investment policies ("we need budget for the total investment!") that some companies have and look a bit more into contractual aspects.
  • Elisabeth had interesting case and lots of energy in her talk about "Get Real". "Spec" mean speculation :o). I tried to ask about how she has overcome the problem of Product Owner speculating as according to my experience there are lots of teams doing the WRONG thing RIGHT. In addition I think it is not Lean to learn what is the RIGHT thing to do by iterating it with implementation and demonstrations. I felt I failed to deliver the question so I might get back to Elisabeth about it. So far I have heard Eric Ries talking about solving this issue with Customer Development and it would be nice to hear how others are solving it. (How Eric has done it (compare the slides 21 and 22)). I feel Customer Development is not been discussed enough in agile conferences as we have Product Owners to abstract that issue (but very rarely ScrumMasters/kanbanists are able to coach the Product Owner to do customer development...).
  • It was interesting to hear Ola speaking about sex. :o)
  • Enjoyed the dinner with Lars and Lasse ;o)
Overall it was a good conference.