Physical Flow vs. Virtual Flow

The fun part about actually seeing flow is just that … we can see it, touch it, interact with it and do something about it to improve it. This is easier in a factory, where the concept of applying the principles behind flow were first written about.

As a “lean leader” in an IT organization, I had the opportunity to consult with a local manufacture of lift equipment as part of my lean leadership training. This experience was invaluable to me (like one of those MasterCard  priceless moments commercials). I got to see immediate opportunities by visually inspecting what was happening on the factory floor and work with my fellow consultants on improving the flow for the hydraulic lift sub-assembly.  Essentially we were leading a week long Kaizen for this area of the floor. The fun part was working with our ultimate consultant, one of the Japanese Lean sensei, interpreter and all.

I could have stopped there and chalked it up to a good experience, but that would have been a waste … instead, being ever curious, I started visualizing the entire lift device (see the picture) as my project and all the pieces and sub-assemblies as my stories and features.

Each sub-assembly delivers a specific portion of functionality to the whole so that bit by bit the thing is delivered.

This is what we do in IT projects (and in technology product companies). We define our goal/vision (the scissor lift), and we build it within increments of parts that flow within sub-assemblies (tasks/stories/features inside iterations). But how do we deliver it?

The part to focus on is the flow … the piece … the part. (some folks use a relay race metaphor…focus on the baton).  The manufacturer monitors and works hard to achieve flow of the scissor lift and the flow of the sub-assemblies that add value to the scissor lift becoming complete. The manufacturer in this case has very specific timings to complete the sub-assemblies so they are ready for the scissor lift at the appropriate time (in this case it was a little over 5 minutes if I remember correctly) … when this happens, the place hums .. it flows … everyone in sync … and we can SEE it (it is a thing of beauty from a geeky process point of view).

We in IT measure the flow of requirements and work towards building our technology solution bit by bit … at least I would hope we do. Flow is what the entire business cares passionately about … flow of information, flow of business value.

When we care and focus on flow, we naturally start looking at those requirements as very valuable whole pieces … we don’t have to wait to deliver an entire technology solution to the business in 1.5 years … we can deliver something in weeks to a couple of months … why wait? We can deliver that portion of the shopping cart experience now … we can deliver the single sign on capability now … we can deliver the <add your feature here> now. Why do we think we have to package a bunch of stuff up? I guarantee you the entire business would have so much more trust of IT if we delivered in short cycles … it is about responsiveness. The business cannot afford to not respond to the world, why do we make them wait on the technology to do so? We rob the business (of which we in IT are included) of revenue now when we have to wait on technology.

Yes, sometimes we wait to initiate projects based on priority and the capacity of our IT system. However when we commit to a delivery as we have capacity to do so, why do we then do so in a fashion that is slow to respond?

Think Flow. Think Small. Deliver. Respond.

Reap the rewards of doing so.

Next time … based on search criteria to find and read this blog, I see people are very interested in flow … specifically value stream mapping … so perhaps something on VSM and then responsiveness.

 

Flow is better – part two

Following up from my last post a few weeks ago (Scrum is Good, Flow is better)  … as promised more about the flow model.

The interesting thing about a flow base model is that we (technology teams) already operate within this model…we just rarely visualize it.

If we did visualize it, we may be shocked at some of our inefficiencies.  We may call ourselves agile or plan driven or have a defined SDLC or use RUP or Prince 2 or <add your project management framework here> … they ALL follow some sort of flow. The question then is … How fluid is our understanding and delivery of business value?

Say you are at a party and someone is truly interested in your work and asks you to describe:

1.  How you deliver value
2. How you know when the value has been achieved

How would you describe this? Understanding and mapping out your execution delivery model … the flow of value … helps you answer these questions. Further, mapping helps us answer why we should care.

In my earlier post (Scrum is Good, Flow is better) I described one team’s delivery model … their SDLC. The team members were trying to be good Scrumologists however things were just not working out the way they had planned (sprint/iteration plan that is). This was because they were applying a prescription (Scrum in this case) to the wrong problem. Mapping out their flow, however, one begins to see why.

The time boxes in Scrum are good, but for different reasons than what this team was using them for. They were getting hung up on features spanning multiple sprints … do we need to work harder, can we break things down even smaller … I don’t know, the refill card story seems small enough already … It was the system (their flow) in which they were operating in that was not in sync with the prescribed time boxes.

The answer lies in “learning to see”  … or better, “value stream mapping for lean development”. When we, as a team, get frustrated with not delivering “as expected”, we tend to blame the customer (they can’t communicate what they really want), the business (they can’t communicate priority), the people (they need to work harder) … why is this? Why do we not look at the system instead? Again, mapping it out and visualizing flow helps us see.

Many excellent resources exist to assist in understanding how to map out a  flow model … even Microsoft offers a guide for Visio (http://office.microsoft.com/en-us/visio/HA101130241033.aspx), too many of them are focused on the factory, search for software development value stream mapping and you can find some samples.  Below is an example found at such a site: 

IT service request FLOW

Essentially it maps out the flow of information and the flow of value. How do technology teams deliver value? By delivering what the business describes as value … typically features or system functionality, thus we want to visualize the flow of those features across our delivery system (our SDLC). This is our flow model. How fluid this model can be depends on how we understand and deliver value.

Is their value in waiting while we batch everything up?…probably not. Is their value in adding “just in case” functionality?…probably not. So what is valuable then?

Value delivery is understanding what we as a business (NOT they the business and WE the IT group … WE THE BUSINESS) care about … and using a system to deliver that value quickly, efficiently and meaningfully. Visualizing our flow and questioning every step, every delay, every delivery helps us achieve a more meaningful value delivery. The team in my earlier post, had to understand how to deliver value. They understood value to the point of working in small feature and functional delivery, it was how they did it that needed understanding. They had to map out how value flowed within their system of specialists. Once that is understood, we can manage the system of delivery instead of blaming the customer, the business or the people.

Next time … how physically seeing flow helped me understand and relate this to Information Technology.

 

Scrum is good, Flow is better – Achieving Flow with Specialists

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