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.

Notes

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.