I am finishing up consulting with a couple of information technology team PMs in a local company and completed my recommendations report. I am communicating here what I communicated to this company. The interesting thing about this company is how they have segmented themselves into specialties. These specialties include design, information architecture, functional analyst, front-end development, back-end development, testing, and copy (for website features). Note: I am not passing judgement on this team configuration … in this case, the organization recognizes that people have passion around areas of solution delivery vs. creating generalists.
The struggle that some teams in this company have with Scrum is managing features and stories within Scrum boundaries. The outcome from the struggle is seen in extending multiple stories into the next iteration, stories getting “stuck” within the iteration, wondering why stories are following this pattern, having too much in flight and managing defects that crop up from prior iterations.
I have been coaching them on managing flow. It is not as simple as saying “get your stories done in the iteration”. When teams segment themselves like this, they will struggle with the boundaries of Scrum.
Specialist based teams may manage and communicate progress much easier and more meaningfully by using a Flow based model vs. a pure Scrum model.
A Flow based model (think Kanban – signal to pull the next feature – for you Lean enthusiasts) allows the team to manage features or stories across their delivery system. This is the critical element … think SYSTEM.
System thinking allows us to “right size” a process (Scrum in this case) into what we as a team are faced with. System thinking is reality based thinking.
Scrum is, to these teams, a prescriptive solution to the wrong problem. Scrum does not work well enough with how these teams are structured. Yes, the principles behind Scrum are good, yes breaking work down into meaningful feature sets is absolutely the right thing to do … proper flow however for these teams comes not from the structure Scrum teaches but rather from queuing theory.
Plenty of material exists on queuing theory so I am not repeating it here. Basically, these teams benefit from queuing theory because each of these specialists represents a queue. The flow of these features/stories shows that these features must be touched by most of these team members. To say that the feature is “done” requires that it have some aspect of it completed by design, IA, FA, devs, copy, tester, business … with this many hands touching the feature, one may begin to see why a pure Scrum framework becomes a prescriptive and frustrating model just to say “we are agile”. Managing the flow of the features within a single timebox queue (aka Sprint) for these teams is frustrating because we can’t visualize what is actually going on underneath the cover of the Sprint cycle….thus the need for a Flow based model.
A Flow based model monitors the steps (queues) that the feature traverses on its journey towards done. A Flow based model measures the cycle time (time from “approved feature” to “approved for delivery”) and allows the team to communicate REALITY based on their SYSTEM of delivery. Notice the graphics below. The first is a visual “andon” of the system and features flowing within the system, the second is a chart to monitor the “health” of the system (cumulative flow diagram).
If you say … “this looks like a waterfall model where I hand off to all these departments” … you would be communicating a gross error. Unlike a large “batch and hand-off forecast” model, note that we break work down into business valued features … those items small enough to flow, implement and deliver value quickly. We then allow the feature to flow based on how we operate our system. Because we examine our work (features) within a system, we can then manage the queues and the capacity of those queues.
The very excellent aspect of visualizing our system, is that we can stop pushing and cramming things into it and instead pull things along smoothly as we have capacity to do so…think of the Flow model graphic above as the “IN PROCESS” queue within Scrum expanded out to reflect reality of what that “in process” really means within our system. When we have too much in process we get … stories we can not complete, stories that are stuck, defects that we push into other sprints … etc.
Now with this view and flow management, we can see EXACTLY what our system is capable of and measure the flow of features … called cycle time. Over a short period of time (say 15 to 45 days depending on how big your system is) we can communicate how many features our system is capable of back to the business, thereby managing expectations and delivery.
Next time … more about the flow model, the usefulness of timeboxes and how people execute within this model …
Phillip Cave
