The Case for One-Piece Flow (Part 2/3)

March 10, 2009 — Posted by Guy Beaver

Part 2: How organizational focus and visual controls that limit work-in-process (WIP) can make large enterprises much more productive and easier to manage

In this 3-part series, I'll cover how too much work-in-process leads to hidden waste at the individual, release, and enterprise levels.

Lean Principles suggest that visual controls that are guided by the value stream help eliminate waste. What is needed is a guide that provides a clear line-of-site from each task being worked to vision that describes how the business wins in its marketplace. This article suggests visual controls that couple the Lean portfolio with work in-process.

I once walked a CEO of a medium-sized company through the area of an experienced, well-formed Agile team, where a disciplined organization established clear visual controls. We reviewed a product portfolio and release plan, and then worked our way to the area that the developers called "the bullpen." We saw the brief daily stand-up, and then walked over and read the stories and tasks that were committed to that day. There was clear visibility to the value of what was being worked, and a clear line-of-sight to the value delivered when that day's activities were complete. At the end of the tour, the visiting CEO exclaimed "I know exactly what each and every person in this organization is doing today. I go for months without knowing what is getting done in my organization."

Minimizing WIP through Lean-Agile product development is an unmatchable way to ensure that focus occurs at all levels in the organization. Distractions and task shifting reduce individual efficiency to the tune of 20% with each interruption [1], and this effect integrates through the organization. Economies of scale achieved by creating functional silos of subject matter experts is quickly lost when the only way to get projects completed is through a hand-off matrix. Even worse, these functional silos become constraints to getting business needs met quickly, because each area must work on multiple projects, with little or no visibility on capacity or impacts of waste.

A division head of a large financial services company was once complaining to me about how no one in his 800 person organization seemed to share his sense of urgency. His rational was that when he got to work, and when he left, the parking lot was mostly empty. His consultants had sold him on the "force to load" approach, where every individual was administered to as much work as possible, and projects were delayed and extended in an attempt to balance out the burn rate of the organization. If keeping people busy is important, then this approach is justified. If cycle time required to get good business ideas and needs to market is important, then perhaps other visual controls are required.

Queuing theory is a mathematical discipline that attempts to minimize cycle time for real world scenarios like standing in line, routing internet packets, manufacturing computer chips, and traffic patterns. For random processes like product development, a nonlinear relationship between cycle time and capacity utilization reveals that cycle time increases (and predictability decreases) as larger pieces of work are loaded into the system. In software development organizations, this effect can be generated by pushing large projects through a matrix, hand-off organization combined with the goal of 100% resource loading (i.e. "keeping people busy").

Instead create pull. But this requires visibility into continuous prioritization with just-in-time decomposition. Discovery (and its impact on predictability) is maintained by breaking things down into smaller chunks, where estimation is on size and not duration. If this is part of a release plan, then clear line-of-sight is established. Note that this only works, if business drivers are incorporated into the near-continuous prioritization of this release plan, otherwise, the organization is de-focused and distracted because there is no motivation (or reason) to minimize WIP, since "it's all important". With proper business guidance, the teams can begin to leverage rapid feedback, and help business solve problems in a market speed. Once this takes root, IT can build back the trust that is commonly lost due to delays in getting what is needed to the business.

Visual controls can ensure that this machine is running on all cylinders. We recommend that the product team manages a clearly visible backlog that shows high level features (e.g. white cards) that are prioritized or sequenced by business need. Delivery teams are kept aware of any changes by the following simple rule: All estimates on the Product Manage team's backlog are provided by the delivery team and only the delivery team. The estimates should be visibly written on the cards, and the teams should become habitual viewers of the backlog, looking specifically for stuff with now estimates. Once items without estimates are discovered, the teams should briefly review what the item is, and if it triggers conversation or technical enabling stories to appear on the board.

The delivery team's visual control is of course, the iteration backlog or Kanban board. The Product Management team is kept aware of status on this board by the following simple rule: The Product Champion (and only the Product Champion) decides when the done criteria of the story are met. This has the added benefit of focusing the team on completing stories in a regular fashion that emphasizes the minimization of WIP (actually in this context, it means opening as few stories at a time as possible). In doing so, flow of completed work is established, and the teams must fully utilize cross-functional collaboration in order to systematically complete end-to-end validated stories.

The image below represents the visual controls, and how they provide visibility and line-of-sight from business drivers to all work-in-process.  

Visual Controls

Figure: Visual Controls-- the Product Management team manages the Product Portfolio (White=Feature, Yellow=Story). The Technology Delivery team manages the Iteration (Sprint) backlog (Yellow=Story, Blue=Task).

Once these visual controls are established, a CEO can walk through her organization, and quickly be aware of what work is in process, and if properly sequenced, rest assured that each person is working on the most important task from a business value perspective, and not simply "keeping busy."

What are your teams busy doing?

References

  1. http://www.apa.org/releases/multitasking.html
  2. Lean Portfolio Management: Guiding IT Projects with Business Value, Better Software Magazine, March 2009.
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Guy Beaver

Guy Beaver was VP of Enterprise Engagements and a Senior Consultant. He is a seasoned technology executive known for building Lean organizations that are driven by business priorities. With 30+ years experience in Financial Services, Aerospace, Health Care and eCommerce, his technology accomplishments include managing enterprise web development and delivery for world class transaction systems (16 Million users), large data center transitions, and SaaS operational excellence utilizing Lean IT practices. He is skilled at organizational change and is the co-author of Lean-Agile Software Development: Achieving Enterprise Agility.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban