Make Your Process Workflow Explicit

Posted on August 4th, 2009 in Agile, Kanban by siddharta || 2 Comments

One of the problem of Scrum is that it leads you to believe that there is no workflow at all. Stories are started, they go “in progress” and then they are done. Unfortunately this leads to a myopic development oriented view of the project.

What happens after the task is “Done”? Usually it is bundled up in a release and given to a customer. The customer takes a look at it and accepts it (or not), possibly with some changes and feedback. In other words, there is still a way to go before it is actually Done.

Done -> Released -> Customer Approval -> Ready to Deploy/Deployed (This is when it is actually Done)

Chances are you have all these implicit steps, unless your customer is sitting with you and approving stuff as you develop it.

What about before the sprint starts? How does the story get into the sprint backlog?

The stakeholders have done some analysis on what would be worth developing, possibly in consultation with other people. Possibly the stories that are scheduled for the upcoming sprint will have a bit of work done on them. A certain amount of detailed elucidation would have already been done. Chances are the user experience folks have done a bit of work on how the feature should behave, possibly running through a mockup or two. Some acceptance criteria would have been finalized. All this happens while the story is still in the backlog, so that when it gets scheduled into a sprint, its ready to be developed.

In other words, before even starting the sprint, the story has run through a workflow, possibly like this

Added to backlog -> Analysis ->  UI -> Not Started (in the sprint)

Again, you probably have all these implicit steps, unless you have your analysts and customer and user folks all sitting in the sprint plan meeting and figuring things out.

What about “In Progress”? Unless you have everyone sitting together and doing the coding, testing, pair programming etc simultaneously, you possibly have a few steps there too. So what scrum calls “In Progress” is actually a bit more detailed. Maybe like this

Build -> Code Review -> Test

So your IMAGINED workflow is like this

Not Started -> In Progess -> Done

but your REAL workflow looks possibly like this

Added to backlog -> Analysis ->  UI ->  Build -> Code Review -> Test -> Released -> Customer Approval -> Deployed

In other words, Scrum completely ignores all the workflow that actually happens implicitly in most teams. This is because there is generally a deep aversion to handoffs (with good reason). With a 3 step workflow it looks like all handoff has been abolished.

But handoffs happen, even in Scrum. Someone details the story when it is still in the backlog. The team then picks it up and works during the sprint. Thats a handoff. The team completes the sprint and gives a release to the customer. Thats a handoff. Then you have mini-handoffs, like between code and test during the sprint.

Only thing is that these handoffs are hidden away from view under pre-sprint activities, post-sprint activities or within the “In Progress” state.

So whats the issue?

When you can’t see these workflows you can’t identify impediments in the process.

An example: Team releases to customer every two weeks. Customer never gets around to seeing the release and accepting it. Team keeps making releases on schedule. As far as they are concerned, they are doing perfect Scrum, burning down their backlog, making frequent releases. One fine day, the customer rejects features from the first release – and wants a whole lot of changes.

What happened there? What the team is actually doing is piling up work in progress in “Customer Approval” state. They think they are getting “Done” with the backlog, but they aren’t really. There are a few more steps to Done. Problem is that the team never realises this, because it is hidden from view. Until the day when the customer comes back with all the changes. Thats when everyone realises that these were never Done to start with. It was still work in progress – only hidden out of sight.

What if the workflow had been more explicit? Had the team tracked Customer Acceptance as a separate state of the workflow, it would soon become evident that work is piling up there – a bottleneck. The team would identify this early and come up with a suitable way to improve the process.

This is why it makes sense to look at your process and figure out what your real workflow is. Then make it explicit so that you can see what is actually happening.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

2 Responses to “Make Your Process Workflow Explicit”

  1. David Draper Says:

    In the most part I agree. In fact I blogged a few weeks ago on visualising these workflow steps outside of the sprint. here.

    On the other hand we do need to take care to retain the workflow within the sprint as property of the team. I have invited teams to describe their workflow, even make it visible if it helps them. But they must own it and be free to change it over time.

    I see a risk with the current enthusiasm for Kanban that managers are taking back workflow and Kanban as a means for directing the team.

    Fortunately, so far I have seen no evidence of this, it’s just a niggling concern.



  2. siddharta Says:

    Hi David,

    I’m not advocating that managers impose a workflow, rather look at what you are already doing and make it visible. If you are doing build and test in a single step, then by all means keep it as a single stage in the workflow. The problem arises when you are doing a workflow in practice, but its implicit and not made visible.

    Nice blog post btw. Like the use of cumulative flow graphs. They are very useful indeed.

Leave a Reply