Lean Economics 101: Parallel Development Is Killing Your Productivity!

By April 9, 2018Agile, Article, Lean

Railroad Tracks

This is another in a series of blogs on the topic of Lean Economics, emphasizing the economic aspects of product development. You can find the first post about WIP limits here

 

As a developer, do you work multiple projects in parallel? As a leader, do you have a team which works multiple features in parallel? Is there more work than people?

Parallel Development is working multiple projects or features at the same time, as shown in the diagram below. It is a common situation I often see when coaching or delivering training. Parallel Development has, unfortunately, become commonplace in industry and accepted as the default standard way of organizing work as our work lives become busier and busier–just assign more and more projects to people, and hope they figure out how a way to get it all done!

Managing 3 high priority projects in parallel development

Often times when I query for reasons behind this type of work model, the refrain is a familiar “We have more work than people. Thus, our people need to be good enough to work multiple projects and show good progress on all of them.”

Parallel Development: The Efficiency Killer

There are many disadvantages to Parallel Development including:

  • Delayed delivery of business value
  • High cost of context switching
  • Inefficient work model
  • Low employee morale

 

All of this can lead to a frustrating work environment where employees are routinely interrupted to begin work on a new project with no regard to their current workload. Everyone is 150% (or choose your number) allocated piecemeal across multiple projects. If the feeling of “starting is common, but finishing is uncommon” is pervasive, then your current work model is economically challenged and likely needs a major adjustment.

In a Parallel Development approach, the business value of each feature is delayed as the team members routinely multitask by working on multiple projects and features as shown in the figure above. Time lost in context-switching can be more than time applied to business value. Often in this situation, the desire to “show some progress” to all stakeholders is deemed more important than delivering value at the earliest point in time.

Serial Development: A Better Way!

The good news is this: there is a better way! Serial Development is when the Agile team focuses on a single project and single feature at a time.

Advantages of Serial Development include:

  • Consistent, early delivery of value
  • Limited context switching
  • Focused development work
  • High levels of employee satisfaction

Serial Development requires courage!

It requires the courage…

  • to ruthlessly prioritize features–not only within the same project but comparatively across multiple projects as shown in the figure below.
  • to allow the team to focus their development efforts on one feature at a time.
  • to inform your stakeholders as to when their features will likely be developed instead of “We have started, but not much progress yet”.

And Serial Development requires courage in the form of coaching your stakeholders that Serial Development will help ensure that their feature(s) gets the development team’s attention at the absolute earliest opportunity based on prioritization.

Managing 3 projects with a prioritized team backlog

Comparison: Context Switching

Not convinced? Let’s compare Parallel Development versus Serial Development in terms of context switching. Parallel Development experiences significant context switching costs as the team members bounce back and forth across multiple features and projects trying their best to keep everyone happy. The generally accepted authority on the cost of context switching comes from the seminal book Quality Software Management: Systems Thinking by Gerald M. Weinberg.

n of Parallel versus serial development in context of context switching

In summary, if you are working on 5 projects in parallel, you are only 20% productive! Moving over to a Serial Development model will help you gain back the 80% productivity lost in context switching. Multiplying this by all members of your team can result in significant levels of productivity gain for the entire team!

Comparison: Value Delivery

Now let’s compare Parallel Development versus Serial Development in terms of delivery of value. I’ll use a simple example from one of our training courses. This example is feature-based but also applies to working multiple projects.

Setup: You work on a team that has a team backlog consisting of 3 features: A, B, and C. Each feature takes the entire team 1 month of time and delivers 1 unit of value. Let’s investigate the value graph across two scenarios – Parallel and Serial Development.

Scenario 1: Parallel Development with an assumed 40% context switching overhead (ref: Quality Software Management: Systems Thinking). The team multitasks across all 3 features making some progress each month (approximately 20% complete) while experiencing the context switching cost. At the end of month 1, no feature is completed. At the end of month 2, no feature is completed. Same for month 3, and same for month 4. Finally, at the end of month 5, the team delivers all 3 features.

Scenario 2: Serial Development focusing on 1 feature at a time. At the end of month 1, feature A is delivered. Context switching cost is minimized and occurs only during the planning associated with kicking off work on the new feature, e.g. during sprint planning and backlog refinement. The team delivers predictably, early and often, 1 feature per month. Delivered features continue their value month-to-month as the next feature is being worked on.

                                                        Parallel Development graph value over timeSerial Development graph value over time

Comparing the two value graphs, which is better in terms of value delivery and cost of delay? In the Serial Development approach, the customers not only enjoy the incremental value of the features delivered as soon as possible, but they receive all 3 features in total much earlier than in Parallel Development!

Comparison: Revenue

As a final comparison, let’s look at a simple revenue example. In the above graphs, assume each feature delivers $100,000 of revenue each month.

For Parallel Development, the total cumulative revenue at the end of each month is:

  • Month 1: $0
  • Month 2: $0
  • Month 3: $0
  • Month 4: $0
  • Month 5: $0
  • Month 6: $300,000

For Serial Development, the total cumulative revenue at the end of each month is:

  • Month 1: $0
  • Month 2: $100,000
  • Month 3: $300,000
  • Month 4: $600,000
  • Month 5: $900,000
  • Month 6: $1,200,000

For Serial Development, the total revenue at the end of month 6 is 400% greater than Parallel Development. The bottom line for this example – developing features serially delivers the business $900,000 in additional revenues!

Four Steps to Begin Serial Development

  1. Ruthlessly prioritize the feature requests across all project demands.
  2. Group the user stories in your team backlog based on a single feature for a single project.
  3. Pare the stories down to a minimum marketable feature that can be launched. Ideally, the team will be able to complete the highest priority minimum marketable feature in the next sprint (or two).
  4. Encourage swarming within the iteration to focus on a few high-priority user stories and complete them as early in the sprint as possible. Effective use of WIP limits can lead to swarming

 

Stop the madness! Parallel Development is wrought with waste and creates a chaotic environment for employees. Serial Development is a much more economical work model ensuring the earliest delivery of value to the end customer and higher employee morale. If your team members are currently mired in Parallel Development, then take action to shift over to a focus-based Serial Development approach. This may take a bit of courage and hard work, but the benefits are so well worth it.

 

Join the discussion One Comment

  • Dana V. Baldwin says:

    Fantastic article. On the road to a high-performing team I usually assert that we can indeed do twice the work in half the time if we address 2 immediate wastes, quality and context-switching. I’ve used a game to demonstrate in the past along with the first chart above but adding this simple example will be fantastic. You guys are great.

Leave a Reply