Agile XP Meets Critical Chain – Part 1: Getting Faster Delivery

Stopwatch

In my last post, I described how I was re-schooled in the basics of project management with the discovery of critical chain methods. We got amazing results by applying critical chain to our traditional software development projects:

  • We challenged ourselves to find ways of delivering faster. This drove us to think backwards from the deliverable — what was really necessary, what could be worked concurrently, and what were the missing dependencies.
  • We created work plans that minimized multi-tasking.
  • We changed our work behavior to mimic a team relay race by:
    • Starting work on a task only when it was truly ready (all dependencies were complete).
    • Remaining heads down on a task until complete or blocked before picking up the next.
    • Working each task to maintain quality and beat the schedule.
    • Helping others when we had gaps between assigned tasks.

But how do these apply in projects using Agile’s Extreme Programming (XP)?   

The Fear of Agile

I first engaged Atomic as a customer, trying to build a sizable software product. But I had no clue how to apply critical chain to the new environment of programming pairs, test-driven development, weekly iterations, and estimates done in points. What the heck was a point?

So I did what any smart customer would do. I pulled rank and ordered that the estimates be done using aggressive but possible (ABP) and highly probable (HP) times. Oh, and I would be responsible for the project plan.

The Atomic team was compliant to the demands of their customer, but something did not sit right with me. I learned long ago that there is more than one way to implement a concept. Was I insisting on a method that was out of context to this new way of working? I began to look deeper.

What unfolded was a discussion and discovery of how XP methods had already implemented many of the fundamentals of critical chain project management.

To share all the things I learned will take several posts. But let’s start with the first area: challenging ourselves to find faster ways of delivering.

Do More Than Just Rock the Boat

If you want to really get faster, get ready to challenge tradition and sacred cows. You will not be just rocking boats; you will be taking dynamite to some of them.

There is a video showing how a house can be built in less than four hours. I remember seeing it for the first time and being floored by how much we accept the status quo as reality that cannot be changed. Yet it was obvious that the normal 90-120 days to build a house was based on how we traditionally staffed, batched, and sequenced work. If we look beyond the thousand workers used in building the house, we can see some valuable things we should do.

How to Speed Up Any Project

There are three things to consider at the beginning of any project.

1. Scope – What is really needed, and when?

Too often, we have thought about the deliverable so completely that we no longer separate needs from wants. We no longer think about time phasing the deliverable to match its real use. We no longer think about alternate ways to provide equal functionality.

This can be a sensitive set of assumptions to re-question, but this area often yields some of the greatest breakthroughs in delivering faster. Start the challenge by asking the team how to deliver in half the time. Once they get over the shock, guide them by asking if there is a smaller version, or other alternate ways of providing similar solutions? Could time phasing be used? Could we work with outside teams differently?

2. Concurrency – What are the real task dependencies?

We often accept that things need to be done in sequence because we only have a few people and they have to work tasks in sequence, or we create dependencies because that’s the way we have always done it.

But there’s a better way. Once the scope is settled, work backwards from the deliverable, challenging the necessity of each task and its dependencies. Do not allow a dependency to be created based on resourcing, except when continuity between tasks is absolutely essential. Once the real tasks and dependencies are known, look for ways to apply resources (people and technology) to work tasks concurrently in a way that compresses the project timeline.

3. Work Methods – Is there anything that can help us speed up work?

Look around for technologies or different methods that can save us time in executing tasks or enable a new level of concurrency. In the 4-hour house, they applied chemicals to the concrete to get it to cure in 20 minutes, and they used a crane to lift the roof into place allowing it to be built at the same time as the walls.

XP Cuts More Waste by Fine-Tuning the Scope

Because they were using XP, the Atomic team delivered a tested, operational version of the application each week. They then asked me the same vital question based on Agile’s first value principle, “What would be the most important thing to deliver next?”

In all my years in IT, I had never heard this question during a project. Once a project scope was set, we assumed everything was necessary.

The reality is, there’s no way to know if you need everything on your specification, or if your specification is complete. But as the application grows and you’re able to see and use it, you get confirmation and clarity. You have the power to change the scope and get the features that really are necessary.

We used two guiding questions to help us do the most important things first:

  1. Which features would get us to making money or accomplishing our organization’s goal sooner? (I was surprised how many things we sequenced to the end of the project and eventually dropped because they had no direct impact.)
  2. Were there any parts of the application that had a much higher than normal risk? (We wanted to go after these in the beginning of the project since they represented the greatest risk to the schedule.)

In subsequent projects, I learned to also include Agile’s first principle in challenging project scope. What features, if built and released first, could be used to get revenue or major benefit faster? It’s surprising how tying a deliverable to the bottom line hones the delivery and release plan to a laser focus. I look back now and realize we were beginning to practice at the corporate level what is now known in the start up world as creating an MVP.

I my next post, I will talk about how multi-tasking is removed.

Conversation
  • […] cases outlined in this post were traditional software development projects. My next blog post will cover how we at Atomic Object apply these same fundamentals in our own work using Agile’s […]

  • […] continuing to write about the specifics of managing software projects, I want to double back around to explain the most valuable things that must be done in any company […]

  • Comments are closed.