Join Doug Rose for an in-depth discussion in this video Making agile predictable, part of Agile at Work: Planning with Agile User Stories.
- When you first think about Agile, it doesn't seem like it would have much executive appeal. Many executives come from a project management background. You wouldn't think they'd embrace the idea of a self-organized team. It's a tough sell for someone who's a manager to accept that teams can function well without managers. You'd also think they'd hold fast to the idea of up-front planning. Executives are often pressured to produce three-year and five-year plans. They need to establish long-term budgets and milestones.
Why embrace a framework that upends those goals? So what do executives want from the Agile framework? A short answer is that they want predictability. Usually by the time a manager becomes an executive, they've realized that a plan is not always a great predictor. An executive may plan for three to five years, but they worry about business quarters. An Agile project builds up working software every sprint. That gives them a working, valuable deliverable. The executives can rely on a finished product.
Imagine you're an executive, and you've convinced your supervisors that they need a new software product by the end of the year. Then you're given a large sum of money to deliver that project. You'll get a plan from the development team about how they intend to deliver the software. The plan shows that by the end of the year, you'll have working software within that budget. What often happens with these plans, is that they don't turn out to be reliable. The software takes more time, more money, or both. Milestones disappear, and commitments go unmet.
This may not happen with every project, but it happens enough to be a problem. If the development doesn't go according to plan, they have to make a couple of tough decisions. Should they double-down on the project and add more money, or should they accept a business quarter of wasted effort, and abandon the project? Either one of those is a tough call. Many executives realize that planning and predictability isn't the same thing. They could plan on getting something really valuable at the end of the year, but if they depend on that plan, then they could end up in danger.
Sometimes it's better just to get something that's completed a little bit over time. Having a detailed plan is great, but it's only valuable if it's accurate. When it's inaccurate, it can actually cause an executive a lot of headaches. It means that they've committed to something that they can't deliver. Sometimes it's better to be uncertain, than to be certain about the wrong thing. It's like that old Mark Twain quote: "It ain't what you don't know that gets you into trouble, "it's what you know for sure, that just ain't so." So the predictability in Agile can actually be a big motivator for executives.
Imagine if the executive had sponsored an Agile team for the software. It wouldn't get a detailed plan from the team, instead they'd just establish a deadline. The product owner would coordinate with the executive team, and create the software. The team may run into the same challenges. There'll be changes, the team might rely on software vendors that don't deliver. Agile doesn't promise to eliminate all those unknown blockers that can crush a project. Instead, an Agile team builds up working software a little bit over time.
The project might not deliver everything, but it will deliver something, and that something will work. That makes a big difference for the executive at the end of the year. They'll have working software, they won't just get an unfulfilled promise. The Agile software might not have all the features and functions, but they won't have to settle for an I.O.U. It's important to keep these pain-points in mind when thinking about your executive sponsor. You should always use the language of predictability and delivery. This is especially true if you're trying to convince an executive to sponsor your Agile project.
- Starting with user roles
- Creating user stories
- Grouping stories with themes or epics
- Creating a project charter
- Writing your release plan
- Avoiding common pitfalls