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

July 29, 2009 — Posted by Guy Beaver

Part 3: Managing Enterprise Agility

In parts 1 and 2 of this series, we discussed how the principles of queuing theory and capacity utilization suggest that keeping people busy actually works against minimizing cycle time. When applied to software development organizations, we begin to see how having too many projects underway unintentionally hides wasteful activity. In part 3, we pull together the concepts and discuss why organizations that focus on completing smaller, high value capabilities can realize much greater returns on technology investments.

During dinner at a recent multi-family vacation, I was asked what I did as a consultant. My reply was that I teach large organizations new ways to think about getting work done. I could see that the audience wasn't going to get much out of the lingo that I deal with everyday, so I boiled it down to something that everyone at the table could grasp. Here's how I pitched it:

Say you start your day with a "To Do" list that contains 10 tasks. Each task happens to take about an hour to complete. If you work in multi-task mode, and open each task, the average time to complete each task will be 10 hours. If you work an 8 hour day, you'll go home with no tasks completed.

Now suppose each task was a request by 10 different customers/clients. If instead of juggling all 10 tasks at once you decide instead to prioritize the tasks, and focus on completing them in sequence, you have a chance of pleasing 8 customers/clients. If your sequence matched the importance of the customer (based on whatever business priority you decide), then you "please" customers based on value. Now when we look at average wait time (cycle time) it comes down to 5 hours in this case, as customer 1 saw 1 hour, customer 2 saw 2 hours, etc., which averages to 5 hours. By simply working in priority and sequencing the work, our average cycle time has been cut in half.

(Technically, the average cycle time in case 2 converges to 1 hour, but in this special case I assumed they all hit the start queue at the same time.)

If we extend this model to business stakeholders making project requests, we can see how minimizing work-in-process (WIP) actually allows for a more Agile business model, as higher value work can get completed on its own instead of bundling up lots of requests into large projects, which hides prioritization and slows down the delivery stream of completed work. For a deeper discussion, see Chapter 14 "Seeing Lean" in our latest book "Lean-Agile Software Development: Achieving Enterprise Agility."

I was once invited to sit in on a mid-project review for a large conversion project referred to here as "Big Conversion Release." It had been underway for 6 months (along with 3 other large release projects that were underway and being worked on by the same team). This conversion project appeared in a Release Plan Timeline that looked something like this:

mid-project review

The team of 30 developers, testers, and analysts were spread across 3 smaller quarterly releases as well as the "Big Conversion Release". The review session was for the team to show the Big Conversion Release to the business team. The meeting started with the dev team proudly describing a new UI as a technological breakthrough that allows them to store and retrieve screen information in a database. The meeting went downhill from there…

The team reviewed a parity conversion of an existing app over to the new technology. It was clear that this was the first time that the business team and the testers had seen the screens. Over 100 "feedback items" were created, and most were challenged by the team as "new requirements" and "complex". Finally the IT manager piped up with "We'll capture these, estimate how big they are, and decide if we can do them ". By the end of the session, the business reviewers and delivery team members were visibly in conflict, and a positive session resulted in a deeper chasm being created between IT and business.

Notice also that at this stage of the "Big Conversion Release" project, half the budget was spent, but many new requirements appeared. And to the dismay of this particular business unit, all new requirements were to be prioritized by IT (not the business), based on their ability to estimate and manage the change.

Who was driving? What was the root cause?

By spreading the 30 member team across multiple (in this case 4) overlapping releases, the delivery process slowed down each release, and unintentionally created delays, which Lean principles define as waste. Each project was delayed because of the misguided belief that it's better to keep people busy on multiple projects (resource loading) than it is to minimize work-in-process and allow for capacity to complete discovery work as it occurs before starting a new project. The average cycle time of each project was effectively delayed by upwards of a factor of 4.

The main takeaways from this 3 part series are:

  • Pay attention to cycle time (total time from idea to delivered solution)
  • Adding work to the queue (organization down to individual) increases cycle time
  • Maximizing capacity utilization (keeping people busy) results in unpredictable cycle time

Start paying attention to WIP and cycle time and Lean out your organization!

For Further Reading:

  1. The Case for One-piece Flow (part 1)
  2. The Case for One-piece Flow (part 2)
  3. Lean-Agile Software Development: Achieving Enterprise Agility, by Shalloway, Beaver & Trott
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