Connected Knowledge

The Pragmatic Bookshelf has recently published an article by Ron Jeffries, Estimation is Evil.

I didn’t enjoy it for a number of reasons. The word evil turns the article into a religious argument and sensationalizes it needlessly. I would have preferred to see a model allowing us to calculate the economic value of estimation, a way to see how it can be negative in some cases, and a case study where it turned out to be negative. Besides, I wasn’t even sure the author wanted to make an anti-estimation point as he spent a large portion of the article explaining how to decompose a big unknown into estimable chunks and argued that estimation is essential to selecting work from the product backlog into the iteration backlog. He also devoted the middle third of the article to how the Chrysler C3 project should have been chartered, which seemed tangential to estimation.

Something interesting happened when a colleague of mine sent the article to an internal mailing list of managers and Scrum masters, mostly new to Agile. The mailing list, usually quiet, came back to life as several people felt compelled to write to their peers with their detailed interpretations of the article. Good for them, but most of what was written resembled blind people touching an elephant.

The Elephant In The Room Is Risk Management

If I were to reduce Ron Jeffries article to one paragraph, it would be the one where he says, spot-on, that “the very beginning” is the worst possible moment to make decisions about “all” “requirements.” (This point has nothing to do with estimation, but you’ve already got my point about it.) It shows the relationship between information, decision-making, and risk.

When the decision is forced at the point when the minimum amount of information exists, it carries the most risk. If we defer the decision until more information arrives or somehow create more information before the fixed decision point, we can reduce risk. Estimation is but one possible source of such information and it may be unreliable, expensive to obtain or redundant in the presence of information supplied by other sources. We must discover and pay attention to other sources of information and remember that the goal is not to obtain as much of it as possible, but to make a decision and reduce risk.

The main risk-management modes are: (a) avoid, (b) reduce, (c) transfer (insure), and (d) retain. We can systematically use information arrival to (a) make some decisions risk-free so the question of avoidance becomes moot, (b) reduce other risks, (c) make insurance cheaper due to the risk reduction, (d) make the remaining risks acceptable.

The best moment to predict the SuperBowl XLVII winner was at the end of the game. Predicting that the Baltimore Ravens would win it before the playoffs was a much riskier decision. The Ravens were the fourth seed in their conference and eight of the twelve playoff teams had better records. The probability of a loss was significantly greater than 50% at that point. As the playoffs progressed, information arrived continually and it reduced continually the risk of this bet (bookmakers’ odds, being a fairly efficient market for this particular type of risk, reflected that). After the Ravens’ final defensive play, the risk was completely gone.

You Cannot Bet On the SuperBowl After It’s Over

Of course you can’t. But that has everything to do with bookmakers’ business model (to make money, they need you to carry bigger risk than theirs, so if you carry no risk, they can’t accept your bet) and nothing to do with our ability to use information to inform risky decisions.

Move decision points to the right on the time axis (deferred commitment) and move information arrival points to the left.

Malleability of Software Creates New Risk-Management Opportunities

The last bit of advice may sound difficult to implement in many areas, but many more opportunities for it exist in the world of software. Many Agile engineering practices can fasten information arrival. For example, continuous integration, if done right, can produce information on our product’s integration status tonight — as opposed to a month later. Agile management practices (and engineering practices can strengthen them) can help defer decision points. For example, if a team delivers working software every week, as opposed to every month, decisions about what to select from the product backlog into the iteration backlog can be made three weeks later — and with the benefit of all information that arrived during those three weeks. The difference between potentially shippable and shipped can weeks’ or months’ worth of information — and all the risks the business has to carry that are intertwined with the information.

I have done a lot of work in Service-Oriented Architecture over the years and observed how many technical and business risks arise at integration boundaries. I have found that the appreciation of continuous integration as a primarily social, rather than technical, practice; personas; specification by example; and James Grenning’s learning-test technique (which he describes in the chapter that he wrote for Robert C. Martin’s Clean Code book) are all excellent tools for discovering tomorrow’s problems today. Risk thinking combined with appropriate technical practices simply make the difference between predictable delivery and panic. I have also observed that many ignore this and pay the price.

Lean And Not So Lean Enterprises

The second part of Ron Jeffries’ article that stood out for me (and again it has nothing to do with estimation) is his story of Agile’s first successes and its first failure with the Chrysler C3 project. Jeffries explained how the way the C3 project was chartered — as a complete replacement of Chrysler’s existing payroll systems — set it up for failure.

Every time we start work — on a large project, a small project, a user story, a feature, or an epic — it is a transaction, in which two sides exchange risk. A lot of such transactions happen in the software industry every day without any due diligence, in other words, consideration of all risks involved and how they can be managed with the help of information.

Whether they see it that way or not and whether they like it or not, the Vendor and the Client are tied together in a Lean (or not-so-Lean) Enterprise. The Vendor promises to deliver something valuable to the Client, using their unique expertise; while the Client, using their unique expertise, plans to add more value to deliverable and deliver the total to their Customer. It’s the same value stream. If the Vendor fails or falls short, the Client’s plan fails as well. They trade risk when enter the transaction.

Very often, all consideration given to this risk fits in one sentence: “This client requires a fixed commitment to the deliverable.” Another way is “a more Agile approach.” An assumption is made that the interpretation of all risk information can be encoded in a “groomed”, prioritized backlog and then the Product Owner is vested with God-like powers to produce a prioritized order every two weeks. When Wall Street types use this sort of “risk management” with our money, you know what we all want done to them.

Ron Jeffries tells us a really valuable story how Chrysler, by choosing to charter the C3 project one way over another, unwittingly underwrote a huge amount of risk and, after a string of successes, ultimately footed the bill for the failure.

Conclusion

I don’t find the back-and-forth estimation debate useful. Estimation is only one of many information sources involved in making decisions and managing risk. The real question is how it factors into the decision you have to make today.

My last post, On WIP Limits, Velocity and Variability, explained how variability can combine with certain habits and the ignorance of pull systems to create a situation where a Scrum team repeatedly delivers roughly half of their user stories committed to the iteration. This leads to the questions, should they commit to fewer stories, do away with commitment, replace it with forecast, or do something else?

Before we dive into that question, let’s introduce Toyota Kata. Toyota Kata (which is actually a combination of two katas, improvement and coaching) is a systematic technique for discovering improvement opportunities, quickly capitalizing on them, and building the organizational capability to do it. Application of Toyota Kata in the manufacturing sector was documented by Mike Rother in his 2009 book. A trend that emerged in the software/IT Kanban community in 2012 is to adapt the Toyota Kata approach to the knowledge work. Hakan Forss, a Kanban coach from Sweden, experiments, blogs and speaks about it a lot. Yuval Yeret, an Agile and Kanban coach from Israel, writes about it in his book, Holy Land Kanban.

One of the important elements of Toyota Kata is finding the improvement direction, which is usually done with a help of a shared vision. The vision is usually unattainable, like zero defects or a very small batch size that is wildly uneconomical given the current changeover times. However, the unattainable vision helps find the next target condition, which is attainable and lies in the direction of the vision. The improvement then focuses on solving the problems that prevent the system of work from reaching the target condition. This is dramatically different from the “suggestions” method, where the suggestions can lead in various directions from the current condition. Some techniques used to select suggestions, such as voting, can further reduce the problem-solving focus.

Commitment as an Unattainable Vision

The struggling, unlimited-work-in-progress, over-committing, under-delivering Scrum team from the start of this post (and the previous one) could benefit from this approach. While acknowledging that the commitment is unattainable every iteration due to the common-cause variation, they can use it to find the next target condition. The problem-solving then could focus on the real problems – user stories too large to flow well, expanding work, lack of knowledge sharing through pair programming, division of work that prevents thinly sliced stories, etc.

By contrast, replacing the commitment with forecast, or reducing commitment to “velocity” can have the effect of covering up those problems and hindering improvement.

A prominent agilist posted a question on Twitter that lead to a long discussion: “Can Scrum teams use velocity as the WIP limit for a sprint? Will it take them closer to pull-based planning?”

Several replies quickly followed from many in the Kanban community, pointing out various problems:

Different units. WIP limits are measured in the units of work (e.g. the count of work items), while velocity (and throughput) are measured in terms of amount of work completed in a unit of time (e.g. items per week). Therefore, you cannot compare them as numbers; it’s like comparing kilometres and kilometres per hour.

Constraint on throughput. Using velocity (the average number of stories or story points the team completes within a sprint) as a limit of what they commit to in the upcoming sprint would effectively serve as a self-imposed constraint on throughput. Such constraint has nothing to do with limiting work-in-progress. Kanban actually suggests the opposite as it sets balancing capability and demand as a goal. If throughput can serve as a measure of capability in a given context, then, to the extent that balancing capability and demand involves growing capability, we want to increase throughput, rather than limit it. This can be achieved, indirectly, by limiting work-in-progress, which is, again, different from the work completion rate.

The discussion served as another reminder that Kanban remains in a blind spot of the Agile community. Agile gurus cannot be counted on to figure out some Kanban basics while Kanban community holds frequent, intense conferences where they discuss more complex stuff. But let’s save this for another day and see how this discussion can help real-world teams.

Just Add Variability

Scrum team using velocity as a WIP limit guideline – effectively not limiting WIP

Let’s say a Scrum team decided to set their in-sprint work-in-progress limit equal to the their velocity number, that is the number of stories they’ve delivered on average in each sprint. This means a WIP limit of N and an average of N stories delivered per sprint. Assuming a somewhat stable system, we can apply Little’s Law and estimate the average story’s cycle time to be equal to the duration of one sprint. Now, if there was absolutely no variability, all N stories would be done exactly in one sprint. However, even minimal variability will ensure that about half of the stories would be done by the end of the timebox. (Reference: Donald Reintertsen, Managing the Design Factory, page 18).

This must sound very familiar to mainstream Scrum adopters. A standup meeting goes like this: “Yesterday, I took part in sprint planning and started working on story X; today, I’m working on story X and nothing is blocking me”, “Yesterday, …I started working on story Y”, “…story Z…” And then the team delivers half the stories they committed to.

Lean Workflow

Lean workflow in-sprint with a WIP limit based on understanding of Little’s Law and effects of variability.

Lean workflow – a very simple way to combine Scrum and Kanban – involves limiting work-in-progress within each sprint. (Reference: William Rowden, Lean Workflow: A Parable in Pictures.) It has the effect of shortening the story cycle time and the team can potentially choose it such that the upper control limit of the cycle time fits within the timebox. It follows from the variability considerations presented above that the in-sprint WIP limit should be a fraction of the number of stories planned for the sprint. In the duration terms, the expected story cycle time should be a fraction of the sprint length.

XP and Pair Programming

It is my observation that people who came to Agile many years ago from eXtreme Programming are generally much better than today’s mainstream Scrum adopters at creating well-performing teams and avoiding dysfunctions. By prescribing pair programming, XP takes an approach which can half the work-in-progress and the cycle time, accomplishing essentially the same goal as the lean workflow.

Emergent Practices

It is clear that, after setting the “lean workflow fraction” to 1/2, XP practitioners didn’t stop there. Seeing something that worked, extreme programmers found more ways to slice user stories into even smaller pieces of value, creating techniques such as Product Sashimi and Elephant Carpaccio.

On the other hand, mainstream Scrum teams not practicing lean workflow, whether in its “mathematical” or XP form, may see the opposite practice emerge – aggregation of smaller, related stories into something “doable” by one programmer within two weeks. “I’m working on the FooBar Service, that’s my story for this sprint.” (Where there is one obvious way to slice the FooBar Service into at eight user stories and slightly less obvious ways to slice it into more than eight.) Honk if you’ve never heard this!

I’d like to summarize several patterns where Scrum (a well known Agile process) combines with Kanban (an evolutionary improvement method). These patters are pretty obvious to many agile coaches and people in the Lean-Kanban community. But I feel I need to outline them for a wide audience of practitioners “in the trenches” – especially those who say “we’re sticking with Scrum for now” or “we’ve invested in Scrum and are not yet ready to try a new process.” The important thing that all these patters have in common is that they are options for improvement – just options, no commitment to substitute them for something else – and all of them involve some proficiency or understanding of Kanban.

Combo #1: Scrum with Lean Workflow

So you’re doing Scrum. Now, although the Scrum framework doesn’t prescribe it, do this: map the value stream of a delivered user story (what would count as “done” at the end of the iteration under the team’s definition of done). Establish an end-to-end pull system with a work-in-progress (WIP) limit at every step (design, development, testing, demo, etc.) This type of pull systems are known as kanban systems. Use tight WIP limits (encouraging pair programming and developer-tester pairing) and the stop-starting-start-finishing mentality to cut the cycle time of each story. This reduces the risk of missing the sprint forecast badly or having many unfinished stories at the end of the sprint. This is the most obvious combination.

Combo #2: Scrum with Personal Kanban

You’re doing Scrum. After the iteration planning, you know what stories have been selected and how they break down into tasks. The scrum board shows who is working on what. But that is not all they’re working on! A team member may have 2 or 3 tasks they’re working on right now plus, perhaps an improvement task from the last retrospective. Also, this week he has to take a training class and file some administrative reports. Oh, and we forgot two interviews of job candidates are coming up. And that’s before production issues that will inevitably show up and cause an interruption.

It is very easy to get a killer dose of multitasking, even if the team board shows you’re working on two stories. It is very easy to make sub-optimal decisions when most work items are hidden. Invisible inventory and not limiting work in progress lead to poor flow for the individual and affect the whole team. Personal Kanban brings the invisible inventory back into the open. It limits work-in-progress to establish good flow and to spark improvement on the personal level. That helps the whole team.

Combo #3: Scrum with Portfolio Kanban

This pattern is the opposite of the previous one. You still do Scrum on the team level. As you scale up, apply Kanban to the higher-tier flow: epic stories, large features, and projects. It is those high-level items that break down into user stories delivered in each sprint on the team level. At higher levels, executives scrumming over epic projects in three-month iterations – that doesn’t work very well.

Combo #4: Scrumban

Kanban itself is not a process. As an evolutionary change method, it applies to an existing process with the goal to improve this process. What if the starting process is Scrum? Then you have a special case of Kanban implementation known as Scrumban.

The relationship between Scrum, Kanban, and Scrumban.

Since Kanban does not prescribe the target process (that is, the process you arrive after improving the starting process with Kanban), there is no prescribed target process in Scrumban. The starting process, Scrum, has synchronized cadences: scheduling, delivery, retrospective. It may happen that the target process still has synchronized cadences, like in this example – in this case you’re still doing Scrum, only it’s a better instance of Scrum. Or it may happen that you arrive at a flow-based process with decoupled cadences.

Conclusion

The above are four popular combinations. You can probably come up with more. The important thing they all have in common they help you improve your Agile process and teamwork and they all require some knowledge of Kanban. You can use one or several of these options at the same time, without a risky commitment to a substitution of your existing process.