Many organizations want to see an estimate for your program (a collection of projects with one business deliverable) before they fund it. So, the teams might spend significant time estimating everything the product owners and managers hope will be in the product from today’s perspective.
Or, you might try a “sprint zero” to understand the current set of requirements and the architecture. You get partway through the program and either the requirements change, the teams realize the architecture changes or you realize you mis-estimated. Whatever the problem, the estimate no longer works. Yet, your management wants you still to deliver the program “as promised.”
Before you estimate, consider these three questions and what they might buy you:
- How much would you like to invest in time, money, or learning before we stop?
- Are you ready to watch the program grow as we build it so you can stop us when you don't want to invest anymore?
- What is the value of this project or program to you?
How much would you like to invest?
Bruce is a program manager in an organization starting with agile approaches. It has done fairly well with single-team projects. Now, it has an idea for a significant program (15 feature teams and people across sales, marketing and training). It needs an agile program.
Bruce met with the operations committee, OpComm. One of the VPs said, “We want you to manage Program A. And, we’re new to this agile stuff. How much time will you take and how much will it cost?”
Bruce said, “I can calculate the run rate of the feature teams. Since the teams aren’t multitasking, I can tell you how much each week or month will cost. And, I need to know from you how much you want to invest in time or money before we stop.”
The OpComm members looked at each other. They had never thought of that question before. The Sales VP said, “Well, we want all of it, right?”
Bruce replied, “Maybe not. We will release value every week. We might learn how to release every day, but I know we can release value every week. You might realize the program has delivered enough value in the third month, not the tenth month. In agile approaches ‘all of it’ might not make too much sense.”
“Ooooh,” replied the marketing VP. The sales VP nodded. “We could sell before it’s all done?”
“Absolutely,” Bruce said. “That’s why I’m always asking the product managers and the product owners what the minimum is for a given feature set. If we have to wait to deliver ‘all of it,’ the program takes longer.”
The training VP said, “I know we also want Program B this year, so let’s see if we can invest four months of feature-team money and see what we get. Will that work for all of you?”
The operations team discussed the problem, and decided five months of the feature teams was the right amount of money for now.
Are you ready to watch the program grow?
Bruce was able to deliver that first program in just under five months. The company got lucky and found the sweet spot for its customers. Now it was time for Program B, which was more intense and would require much more interaction with the customers than Program A. Program B had fewer overall feature sets, so Bruce thought he might only need eight or nine feature teams. He thought one feature set might require two or even three feature teams.
When he met with the operations committee, it asked him the estimation question again. This time, Bruce asked, “This product is a huge departure from our other products. The teams will need customer feedback. And, I think we need OpComm feedback, too. Are you willing to watch the product grow as we finish chunks of it? We have a demo every Wednesday morning.”
The marketing and sales VPs both sat back. “I’m set to be traveling for most of the next six months,” the sales VP said. “Can I ask my internal salespeople to watch the demos?”
Bruce thought for a minute. While he was thinking, the marketing VP said, “I’m sending my product managers out for these next few months, but I’ll be in town. Do you trust me enough to make decisions for you?”
The sales VP chimed in, “If you call me and tell me what you saw, we can discuss progress and you can provide feedback to the program.” The marketing VP said, “It’s a deal.” He turned to Bruce and said, “Yes, we can watch the product grow. How about the rest of you?”
The OpComm decided it would watch the program grow and revisit the funding after three months. Program B took closer to a year, but the organization was able to start selling after the first seven weeks. The marketing and the sales people worked closely to manage the customers’ expectations about what their customers could expect (and when).
What is the value of the program to you?
Shelly, another program manager, took a different tack with Program C. This program was an outgrowth of a previous product. The teams were new to agile approaches, and Shelly wasn’t sure she could help them maintain a regular cadence of delivery. Shelly thought she could help the teams develop a regular cadence by focusing on value.
When OpComm asked her for an estimate, she asked, “What’s the value of the program to you?” She asked more questions about the kinds of customers the product should attract and retain, when the OpComm wanted to see sales and what the expectations were for the support model.
The sales VP explained about the several kinds of customers it wanted to attract and retain. The marketing VP spoke about the expectation of market growth. And the CFO spoke about the support revenue it wanted to see and when.
Shelly explained that the support and subscription model might change when the company implemented certain parts of the various feature sets. The OpComm all understood. When Shelly called a meeting of the feature teams, she explained that she was not looking for estimates. She wanted the entire program to build a biweekly and then a weekly cadence of delivery. Several people on several teams protested, saying it was impossible for their teams to deliver faster than once a month.
Shelly conducted an open space activity to help the teams understand their answers to this question: “What will it take for us to deliver value to our customers at least once a week?” The teams left with understanding of the value and action items for their teams to deliver more often. It took a couple of months, but Shelly’s program now delivers value three times a week.
Create resiliency and trust with frequent delivery
Agile approaches allow us to offer ways to manage investment, deliver value and deliver for the organization in various ways. Agile approaches help us build resilience into the programs and the management decisions.
Bruce and Shelly used different approaches to create resilience in their programs. However, they had a common technique: frequent delivery of finished value. You can still create estimates for your agile program. However, you might not need to do so—as long as your program can deliver value on a frequent-enough basis. Consider what will work for your program and your organization.