Delivering Software “Projects” == Waste

Some time ago I experienced an all too common pattern when working with software development teams. This pattern has to do with the way development projects are prioritized and scheduled. In my opinion this pattern is one of the largest areas of waste in the software development field.

I started coaching a new team and within the first few days I met the lady that was assigned to be the product owner for the project (we’ll call her PO). She was from the “business” side of the company and had never heard of a product owner before but since she was a domain expert she got the job.

I was introduced to her in a meeting in which she presented a PowerPoint presentation with what she believed were the requirements for the project. In that meeting I was told that everything in the presentation had to be delivered or the project would not be considered a success. I was even told I would be given a little amount of time to come up with an estimate for how long the project would take. How lucky can one be!

The next morning I was called into the office of a senior manager for the company. In that meeting I was informed that even though I was given the latitude to work out an estimate for the project the budget had already been fixed. In other words, the project duration had already been established but the business wasn’t aware of this. “By the way, welcome to the company”, he said. “Whatever you do, make sure the business is happy with the software you deliver because we are trying to repair a bad relationship here”.

Creating a Map

I proceeded to work with the product owner over the next week. We started by creating a feature map that identified four high level features. I explained to her that we needed to prioritize the features so we can begin working on her highest priority. PO was very quick to prioritize because the business really knows what they want. I proceeded to work with PO to create the next level of features out of the four high level ones. These features were still way too large to work on but they were a step in the right direction.

Next I turned my attention to the team. I scheduled a one hour session with them to provide relative estimates for the 24 second level features PO had identified. I explained to the team that we were not trying to determine how long each feature would take to deliver. We were just trying to determine how large they were in relation to each other. After much coaching and work with the team we came up with relative sizing. Then we rolled it up to the high level features and came up with the following:

High Level Relative Sizing Image

High Level Relative Sizing

The numbers below the bottom left corner of the feature boxes represent the relative size of each feature. We determined that feature 3 and 4 were about twice the size of feature 2 and feature 1 was about twice the size of feature 3 and 4. Armed with this information it was time to regroup with PO.

Where’s the Value?

I schedule a two hour meeting with PO (I know – I hate meetings as well but they were the only way I could get her to spend time with me at that point). I told her the purpose of the meeting was for us to make sure we understood the true value of the features we were delivering. She said that we already knew the value – it was clearly stated in the PowerPoint presentation. I asked her to bear with me as I am a slow learner.

The following is a paraphrase of what transpired in that meeting:

Chzy: I am glad you were able to make the time for me. I would like to begin by understanding the value of each feature in our list.
PO: Why do we want to do that?
Chzy: Because we want to work on the highest value features first.
PO: Why does that matter? You are going to do them all aren’t you?
Chzy: We are going to do our best but sometimes a companies priorities change.
PO: Oh. I see.
Chzy: In my experience that happens more times than not. We just want to make sure that if that does happen we deliver the highest value software possible.
PO: Okay. What do you want me to do?
Chzy: I want you to assign a value to the four top level features. You have 1000 points to split across each feature. There is a good chance you will not get all 1000. You might get 400, you might get 800. We do not know for sure at this point. When we reach that number we will be forced to stop. Therefore, it is very important that you think about the true value each feature delivers to the business.
PO: What will you do with this information?
Chzy: We will begin working on the highest value features first.

I continued to work with her helping her determine which features were nice-to-haves and which ones delivered true value. When we finished the session we ended up with the following:

Features with Business Value

Features with Business Value

PO came to realize that the fourth feature was really a nice-to-have feature. She didn’t think it added zero value but she didn’t want to risk completing one of the other features by working on it. She also determined that about 75% of the true business value was in the feature that she had originally thought was the third highest priority.

What was the result?

The team eventually delivered the third feature only. The project took 2.5 months, came in under the budgeted amount, and the customer was pleased that they received value so quickly.

What would have happened if we had just started with the highest priority as originally determined by PO?

The pattern described above is quite common. Over the years we have trained business people to ask for everything they can possibly think of when requesting software projects. This is a reaction to processes we have put in place in order to discourage them from changing their minds. Can you say “Change Control Process”?

Applied across multiple projects

In this post I want to take this concept one large step further. Imagine if you will a highly functioning agile team. This team is delivering working software every week or two. The force is with them.

The company in which this team exists has four software projects that must get done this year. All four projects are critical for the companies future success. The typical way the company will handle this is to determine which of the four projects is the highest priority, which is the second highest priority, and so on. Some might call this strategic planning. They will expect the team to work them in this priority order.

But what happens if the team is unable to complete the fourth project? This would typically be viewed as failure. My view is that the failure has nothing to do with the team. It has everything to do with how the projects were scheduled.

If we apply the techniques described above at the point where we are doing the strategic planning it could have a significant impact. Imagine the following two projects with the associated features with business value assigned:

Business Value for Two Projects

Business Value for Two Projects

Prioritize Features, not Projects

It is very likely that feature two for project two has more business value than feature one for project one. If that is the case and we have the team focus on project one until completion we are not delivering the highest possible value to the business.

Is this even possible? I believe it is but it will require a radical change in the way we view and fund projects. In a future post I will detail out what those changes look like.

7 thoughts on “Delivering Software “Projects” == Waste

  1. 1) I love the fact that you show how asking for priority and value as separate dimensions / perspectives of a given feature can bring the feature value into focus.
    2) Very compelling point about looking at features in terms of value, regardless the project. I could see this also applying to phases in large enterprise projects. The difficulty I’d anticipate would be that often in large companies there are multiple layers of customer proxies that are too robotic and plan-focused to explore this kind of shift.
    3) It seems that the concept of a “project” may be an attempt to provide a palatable grouping of work so that people see a “done” point. Do you think this is a part of the issue? That some people need major “done” points, psychologically, and others prefer simply to know “what next!”? I suspect it is. And I also suspect the “done” mentality is one that contributes to the “successful” delivery of software that fails to add the customer’s desired value.

  2. Over the years we have trained business people to ask for everything they can possibly think of when requesting software projects. This is a reaction to processes we have put in place in order to discourage them from changing their minds.

    I love this, Chzy. One of the things that not-yet-Agile people don’t take into account is the way process shapes people and decision-making. We don’t just act on the methodology; the methodology acts on us.

    Crazy, unstructured process makes us crazy and unstructured. Flexible and creative process makes us flexible and creative. Rigid process makes us rigid.

    And a process that rewards all-inclusive demands… generates all-inclusive demands. If you make course corrections difficult, of course the product owner will ask for everything up front.

  3. Great post, Cheezy. I work as a product manager and find this approach much more comfortable than the approach which asks for everything up-front. Business priorities change. The ability to change plans quickly is a competitive advantage.

    Do you encounter many situations where the team, rather than the business, have come to believe that “changing requirements” are always bad? If so, what strategies have you used to get the team on board with a process that prioritizes work based on business value, rather than following a plan that was decided a year ago?

    • Rob, the developers view you mention is a very common one. In fact, it is the standard viewpoint with non-agile teams. In order to have a prayer of hitting a date that was dictated a long time ago one must make sure that no requirements change over the duration of the project. If they do change, one must have something in place to allow us to move the end date. This is one of the reasons teams have change control processes.

      One fact that we do know is that things change. The market moves rapidly which causes us to change what we deliver. New competition surfaces ad we must react. Often seeing our ideas become concrete causes us to rethink out ideas. It is almost certain that a plan created a year ago is partially outdated and irrelevant.

      Everybody can agree that delivering the wrong software helps nobody. So the challenge is how can we structure our software delivery to ensure we are working on the right thing without constantly causing rework or thrashing. From my experience the solution is a collection of practices.

      At the most basic level we deliver working software in short increments and have the product owner review it. This provides fast feedback which is essential to react to change. If the product owner reviews and decides to change something we have only a small change since the increment is short as the reviews are often.

      Next, elaborate requirements just-in-time. This reduces rework in requirements management and give the product owner the opportunity to make final decisions late in the process – when they have more information to make the right decisions.

      In development three practices are essential; test-driven development, pair programming, and simple & evolutionary design. These practices keep our software clean and concise enough to absorb change. The also provide the safety net to allow frequent change.

      Our testers must have automated tests for the application to ensure we do not introduce a regression error while we are making changes.

Leave a Reply

Your email address will not be published. Required fields are marked *