AvailAgility
Karl Scotland – Using Agile to Deliver Value
Posts tagged Workflow
Evolving a Workflow
Oct 9th
Mary Poppendieck gave a talk on Workflow is Orthogonal to Schedule at Agile2009, during which she very neatly transitioned a schedule-focused view of work, into a flow-focussed view. At least I thought it was neat, so I’m going to try and reproduce the basic elements here, using my favourite agile workflow.
4 Week Time-box Schedule
Here we have a schedule showing an average of 4 features being delivered every 4 week time-box. Each time-box is preceded by 2 weeks understanding the next features, and a release is made every 8 weeks. Its not a bad schedule. There’s a regular release every two months which is better than a lot of projects, but it could be better.
2 Week Time-box Schedule
Now we reduced the time-box to 2 weeks, meaning that we do an average of 2 features in each time-box. This means that the preparation now takes only 1 week. Additionally, we are now releasing at the end of every time-box, which is also reduced to 1 week. Much better.
One Piece Flow
If we continue the evolution we end up working on a single feature at a time and releasing it immediately. Each feature only takes a week to build, and preparation and release times are now down to 1/2 a week. At this point, we don’t really have a schedule anymore, but a natural workflow.
Cumulative Flow Diagrams
One of the things that strikes me about the diagrams above, is that each step in the evolution transforms them more into a smooth Cumulative Flow Diagram. In fact, in the same presentation, Mary showed the following picture taken from Building the Empire State. This is the building schedule from from around 1930, and itself looks remarkably like a CFD. Another example of how we are not inventing anything new, but can learn from other industries and successes.
An Agile Workflow
Feb 25th
A common topic of discussion around kanban is whether the workflows or stages in a kanban system are counter to the Agile principles of cross functional and collaborative teams. Its easy to talk about a feature going through the following flow in a kanban system:
Analysis –> Build –> Test –> Release
which I confess looks very waterfall-ish and I can understand why this can raise warning flags about the suitability of the kanban approach. This got me thinking about how best to express a typical agile-friendly workflow.
Lets begin with the common basic stages on an agile team’s ‘story-board’.
To Do –> In Progress –> Done
Ideally, ‘Done’ means In Production, but often it means Ready for Release. From a Lean perspective, features that are ‘Ready for Release’ but not yet ‘In Production’ can be thought of as inventory, and we want to minimise inventory, so visualising that inventory would be useful. Thus we can change the workflow to:
To Do –> In Progress –> Ready for Release –> In Production
Looking at the start of the workflow, a common practice in Scrum is shaping the backlog, or grooming the backlog. This is the process of ensuring that the the Product Backlog Items that we take into Sprint Planning are well-formed. That is, that they are small enough, and understood well enough, for the team to be able to plan and deliver them within the time-box. I don’t think this is Scrum specific. There will always be a step of taking a business problem or goal, and transforming into pieces that can delivered incrementally and iteratively. Sounds like Analysis to me.
To Do –> Analysis –> In Progress –> Ready for Release –> In Production
Features which are ‘To Do’ have not had any significant time invested in them yet but they are generally formed to some extent. We can say that they Incubate. ‘Analysis’ has baggage associated with it so we can give it a different name. I like the idea that we Illustrate what we need to do as it seems to allow for the notion of using executable requirements or other lightweight, quick feedback techniques. ‘In Progress’ now really means ‘Build (and Test)’. We can say that at this stage we Instantiate the illustration. ‘Ready for Release’ means that we can Demonstrate what we have instantiated. This could also include any validation or acceptance by the business. Finally, when a feature is ‘In Production’ it should be generating value, so we can say that we Liquidate it.
So for each feature, one by one, we end up with:
Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate
Does that still seem like a waterfall process?
Model workflow stages – not people or roles
Jan 25th
A recent discussion on the leanagile list compared Scrum and Kanban with respect to team swarming. The suggestion was that swarming doesn’t occur in kanban due to the way work flows from role to another. This is a common misconception, leading to the perception that kanban is more like waterfall than agile. Here’s my response.
Firstly:
I would say that limiting WIP in a kanban system can encourage swarming because team members have to help each other rather than pick up new work
And then:
The stages in a workflow are not people, or even roles. Just stages. So anyone can do them.
It just happens that people tend to specialise their roles to stages.
So kanban allows specialisation, but also encourages people to break out of their specialisation by limiting WIP.For example, I might have an analysis stage, and Bob, a Business Analysis specialist.
If the kanban system has throttled analysis work, Bob could probably work with developers or testers to help them improve their productivity.
And vice versa.
Its this focus on workflow, while allowing for specialisation, that means that kanban is a suitable technique for teams of all agile maturity. As teams learn to swarm, then their agility should improve as a result.
