It’s all about the flow
So it’s not really about the tools and processes. Right? Sure – it’s about people and interactions. Well, that sounds nice, but it’s not always helpful. What sort of people? What sort of interactions? There is something deep-running underneath all the talk and principles and concepts in Agile, Scrum, Lean, and all the rest. Sometimes it’s implicit, sometimes it’s explicit (Kanban talks about it a lot). What is it?
It’s all about the flow, man. I’m not talking some pseudo-mystic philosophy or New Age mumbo-jumbo: I’m talking about a practical philosophy.
The flow of work, of ideas, of software, of value, of knowledge. The people who really understand Lean and Agile understand that flow is at the heart of it all. Small batch sizes and low cycle time enable flow.
Most people focus on velocity
The typical Agilist or Scrum “master” these days is usually focused on velocity. But this is often not a very good metric. It does not encourage flow, it encourages the opposite: big stories and heroics. Teams choosing to tackle a big “13 point” story instead of three “3 point” stories, because their numbers look better. It can also encourage teams to over-estimate, a dangerous spiral.
But smaller slices and batches are always better: less work, less tech debt, less risk. And earlier delivery: earlier learning, earlier value, earlier wins. The first of those small stories will be done way before the big fat story. And remember, agile is about earlier, not faster and cheaper.
We should instead focus on cycle time and throughput
Cycle time and throughput are more valuable metrics than velocity. Cycle time shows how quickly work is flowing through your system. The clock starts ticking when an item of work first moves into some kind of “In Progress” state. It stops ticking when the item moves into some kind of “Done” status. (If you’re not sure about the difference between Lead and Cycle time, I explained it all here).
You should always be aiming to get your cycle time as low as possible: preferably half or less than half of the length of your iterations. If your average cycle time is much higher than that, then work is not flowing through and you are struggling to complete stories in an iteration.
The best ways to reduce cycle time are to use small batch size, eliminate waste, use Simple Design principles and YAGNI (You Ain’t Gonna Need It). All the good solid Lean ideas that everyone should be using anyway.
Most people focus on Backlog and In Progress
A lot of people, especially business analysts and product owners, like to see big backlogs. They think a big backlog is a sign of a healthy product. They like putting things in a product backlog, they like moving things around within a backlog, and they like having meetings and discussions about a product backlog. The problem is, this is all wrong.
A Product Backlog is a form of Inventory, and Inventory is a form of waste. I don’t think we necessarily need to go to the other extreme and have No Backlog (though this is apparently now A Thing, and a hashtag, oh dear). A “Just in Time” approach is better: just enough backlog to feed the team for the next tranche of work.
Other people, especially developers and testers, like to focus on In Progress. They like to see big columns called In Development or In Testing or similar, jam packed full of juicy items to work on. They see this as a sign of a healthy system. The problem is, it isn’t.
Work in Progress is not technically one of the dreaded Wastes of Lean Manufacturing (and Lean Software Development), but it is something that we should try to minimise.
This is fundamentally what Kanban is about: not drawing up lanes on a board with tape, and putting cute avatars on post-it notes, but minimising WIP. More WIP means longer cycle time, less throughput and less value delivered. Work In Progress looks like progress towards value, but it isn’t. The only way to delivery value is to move things into Done.
You should focus instead on Done
The best board doesn’t have lots of things on the Backlog or In Progress, it has lots of things in Done. And very few things in the backlog, and they move out of there very quickly. And very things In Progress, and they move out of there very quickly.
The holy grail of Lean is “Single Piece Continuous Flow”. That is a state where work is broken down into the smallest possible pieces, and where things move through the system as quickly as possible. It is the polar opposite of traditional big batch Waterfall style approaches, where work moves slowly in big chunks with lots of stoppages and phase gates.
So how do you improve flow?
Improving Flow is undoubtedly good for any system. But how do you improve it? Fortunately there are a number of techniques that can help.
Stop Starting and Start Finishing
The best way to improve flow is to focus on finishing in-flight items before starting new ones. I despair when I see teams continually pulling in work before existing things have been finished. The usual excuses and disclaimers pop up: “We have to wait for the environments to get fixed before we can close that off”. “I’m waiting to hear back from the testers for that story”. “The UX is still being finalised so I’ll start on something else instead of waiting”.
Those sound like reasonable statements, but they’re not. How about “What can I do to help get the environments working?” “Can I help with the testing for that story?” “Let’s split this story up so I can work on the bits that aren’t dependent on a UX decision”.
Reduce Handoffs
Reducing handoffs, handovers and dependencies is extremely important. Otherwise work will get stuck and blocked on a regular basis.
This is the main reason why Scrum and especially Large Scale Scrum recommends cross-functional teams. Work shouldn’t have to be handed over to anybody.
A team should be able to complete all the work for a given feature themselves. If that makes the team too big, then consider splitting the feature into smaller pieces.
Work in Parallel
Rather than seeing user stories as moving through mini-Waterfall phases like “Analysis”, “Development”, “Testing”, try and parallelise as much of the work as possible.
Pair, Swarm and Mob
Pair Programming involves two programmers working on a story simultaneously, instead of each working on separate stories. This sounds like it’s slower and less efficient, but many people (and some research) suggests that it’s not. It improves code quality, reduces defects, and decreases the story getting stuck waiting for code reviews (the code reviews happen as the story as being done, rather than afterwards). Swarm and Mob Programming and further extensions of pairing: many people programming at once.
Small Batch Size
Smaller stories reduce ambiguity, reduce risk, improve quality, reduce cycle time and improve flow. There is no reason to do large stories. Over time, teams will get better at slicing stories into smaller and smaller parts. Ideally, they should be able to be completed in one or two days.
Build Quality In
Quality should be built into the process, rather than stuck on the end as a big phase. If you are doing TDD, you start testing even before you start coding. Test Driven Development, Merciless Refactoring, Behaviour Driven Development, Executable Specifications and Automated Testing are tools and techniques that you can use to build quality into the development process. Defect rates should approach vanishingly small numbers over time.
Summary
Agile software development borrows heavily from the traditions of Lean Manufacturing (Tom and Mary Poppendieck’s works on Lean Software Development make this inheritance more explicit). And for good reason: Lean focuses on reducing waste, improving flow, and maximising flow and throughput.
This is the way to true business agility and exponential growth. Not by pushing big heavy stories into progress to try and make random metrics look good, but by quickly pulling small things through a simple, lean system. And that is the power of flow.
