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:
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:
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:
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.