Making agile predictable

- 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. 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. They 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 IOU. 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.