Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.
One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.
Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?
This us where you start talking to people and understanding what the value of everything is.
- Does the program need everything on that team’s backlog?
- Does the program need everything on other team’s backlogs?
- Does the program product owner understand the cost of delay?
- How about the sponsors for the program? Do they know what’s going on?
Take out your back of the napkin calculation and show it to anyone who will listen.
Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)
Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.
Are the teams working by layer, front end, middleware, back end, instead of through the architecture?
Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.
This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.
Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.
Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.
If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.
You have to optimize for the program’s throughput, not any one team’s throughput.
In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:
- The team can ask for technical help from another team (get an architect/designer to work with the team)
- The team can split their backlog among several other teams, to give them a fighting chance.
- If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.
If you don’t ask the team, you don’t know what’s wrong.
The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.
I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.
If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.
If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.
The posts in this series so far are:
- Cost of delay due to not shipping on time, part 1
- Cost of delay due to multitasking, part 2
- Cost of delay due to indecision, part 3
- Cost of delay due to technical debt, part 4
