You're Already Using Continuous Flow (poorly)

Many teams out there are doing Scrum with a 30 day sprint. If you ask them, they'll tell you one of the reasons they adopted this process is to be able to quickly respond to change. If you look at the way they work, it's very much in line with that stated goal. The problem, however, it that what they actually do is totally different than what Scrum prescribes.

Lets examine the process of a typical Scrum team doing 30 days sprints:

• On day one of sprint #1, someone introduces a bug. They don't realize it, and it makes it way through the end of the sprint.
• On day one of sprint #2, a stakeholder happens to be playing around with the version of the product that was demoed for sprint #1. She notices the bug, and it's critical, so she adds the issue to the very top of the backlog. However, planning for sprint #2 has already come and gone, so it will have to wait for sprint #3.
• On day one of sprint #3, a developer fixes this high priority bug. The fix is demoed at the end of sprint #3, and the fix is now (at least, theoretically) ready to ship as we begin sprint #4.
  

This is what your certified scrum master will probably tell you is the "correct" approach. Do we actually address critical bugs this way? Of course not, because waiting 90 days from the point where a critical bug is introduced to the point where it's fixed is absolutely insane! No rational team would do that. Here's what really happens on these teams:

• On day one of sprint #1, someone introduces a bug. They don't realize it, and it makes it way through the end of the sprint.
• On day one of sprint #2, a stakeholder happens to be playing around with the version of the product that was demoed for sprint #1. She notices the bug, and it's critical, so she goes to the team lead and asks to have it fixed right away for the PR demo she's doing on Thursday.
• The team lead and the stakeholder argue about process and deadlines for about an hour.
• The team lead then relents, branches the sprint #1 demo code. He works into the night to fix the bug, test it out, deploy the new version, test it out again, and merge the change into the trunk.
  

At Improving Works, we use a continuous flow process for handling changes. As new bugs and features are pulled from the backlog, they are completely defined, implemented (using TDD) and deployed one at a time. That is, each completed feature or major bug fix results in a new release of the product. As a result, we release often. Very often. Infinitest, for example, is released an average of every 2.1 calendar days. These releases go directly to customers, because until we put those changes in the hands of our customers, they might as well not exist.

What is happening in the second Scrum scenario we outlined above is not all that different, from a process perspective, from what we do at Improving Works. We're both fixing critical bugs as soon as we possibly can. The difference is that at IW, the technical practices we employ give us confidence that our frequent releases will be stable, valuable, and work as expected. Ask the technical lead that hacked out a fix at 2 in the morning whether or not he feels the same confidence, and I suspect you'll get a very different answer.

Pretending that you don't have to respond to a crisis is irresponsible and unrealistic. The Agile value of "Responding to Change" demands that we rigorously employ the technical practices that allow us to react calmly and effectively when things go wrong.

Comments

[Urs Enzler]

I do not really agree with what you describe here.

In my team the scenario would look like this:

1) day 1 sprint 1 -> add bug

2a) if it is really a critical bug that breaks existing features then it is very likely that it gets detected during in-sprint testing -> immediate fix within sprint 1 => delivered within 1 sprint (= 10 working days in my project)

2b) the bug remains undetected and is detected early in sprint 2 -> defect is prioritized high on the CURRENT sprint backlog (we always save some time for defects [critical or not] in each sprint) => defect fixed end of sprint 2 (= 20 working days)

- no late working
- no long delay

The reason why I'm against more "releases" (or product increments) is that our customer and the release testing team can not cope with such frequent releases (installation on several machines, on several sites wordwide).

Of course, from time to time there is the need for an immediate release that fixes an issue but this should be really rarely. So far it happend once in 2 years of development in my team.

Cheers,
Urs

[Ben Rady]

Urs,

Even if you add the defect to the sprint 2 backlog, you're still delivering a fix 60 days after introducing it. Of course, we all do exploratory testing to try and find bugs but some of them can only occur "in the wild". You have to release to find them.

I'm surprised to hear you say that you're "against" more frequent releases. Do you think they're inherently bad? Or just not your team wants to do? What if your release testing team could verify a new version in 30 minutes? What if installation and deployment to customer sites was automatic? What would be the downside of releasing more frequently?

[Urs Enzler]

> Even if you add the defect to the sprint 2 backlog, you're still delivering a fix 60 days after introducing it. I'm surprised to hear you say that you're "against" more frequent releases. Do you think they're inherently bad? <

Not inherently bad, but there is a point where delivering a new release does not outweight the benefit of it. If the ROI (Return-on-Investment) is given for a release then it's okay for us. However, this is normally not given for an intermediate release.

But again, we have to distinguish between fixing an issue on a already released version and a bug introduced on the development trunk that is not yet released. The ROI is totally different in these scenarios.

In my project a product-increment is quite costly to deploy to the customer (several sites, worldwide, specially set-up computers), each has to be verified. And finally a real release (goes to the end-customer) has to be validated by the FDA.