Request Demo
4 min read

6 Challenges to Predictable Software Delivery in Agile

“What will I get, and when will I get it?”  The success of product management and technology leaders hinges on their ability to answer these questions from their stakeholders; and backing it up with a track record of delivering on that promise. If things change, you’re expected to communicate any deviations early and often.

Agile methodologies have undoubtedly taken the industry by storm and established themselves as the best-known method of today. But for all the improvements in transparency and predictability that Agile has brought, it is not without presenting new challenges. In many instances, Agile organizations face the same group of stakeholders clamoring for product development to be more predictable. In our experience, these are some of the key reasons why Agile organizations struggle to deliver software predictably:

1. If you are writing requirements as you go, how do you know what’s done and what remains?

In Agile, requirements are detailed and broken down into smaller work items (i.e. user stories) only when their execution nears. This optimized the waterfall-era writing of an upfront product requirements document (PRD) that would inevitably result in a product getting feedback too late and creating features users may never actually need. With Agile removing that waste, it presents product teams with the ability to pivot scope to most efficiently deliver value. However, it complicated the calculation to questions like “What’s the date?” or “How much is left?”. How do you know how much is left when you’re still defining what you need to build? This is non-trivial to answer, and if you can’t articulate it quickly and clearly, your stakeholders are left feeling like you cannot deliver software predictably.

2. Team velocity doesn’t tell the whole story

Scrum’s key metric is the team velocity, the number of story points that can be completed in a sprint. Mature teams will establish a velocity that can be used to predict how much can be done over time. However, predicting when a body of work will be done by a team can still be challenging even with the most stable velocity. Why? Because teams often work on several things at once. Those 50 story points per sprint could be allocated to multiple features, legacy bugs, and some emergency support/production issues that weren’t foreseen at the start of the sprint. While this empirical velocity is great for the team to use for planning, it’s not as useful if you are trying to apply their whole velocity against a body of work that might only get a fraction of it - resulting in optimistic delivery predictions and disappointed stakeholders. This is particularly painful because the teams are crushing everything in front of them, but it’s not being recognized as it should.

3. Inconsistent team-level processes

Let’s face it, managing across a bunch of Agile teams is hard. Most organizations are making great strides but are far from the utopia of fully autonomous feature teams delivering value independently. If you don’t have a good baseline across teams, your stakeholders will quickly complain that the Agile movement duped them. While high-performing teams should have the flexibility to adjust the process and ‘kaizen’ it to their desires, there needs to be a basic set of common practices. For example, some items are as simple as ensuring teams are stopping and starting their sprints on the timebox they said they would. A team that commonly allows their 2-week sprint to extend a few days to finish more stuff is not only completely missing the point, but their velocity number will be of little use.

4. An uncertain gap between your Definition of Done and customer delivery

A clearly written Definition of Done is an important way to ensure teams can execute on tickets and keep everyone on the same page about what it means when they are in the ‘Done’ state. Depending on where you are on your DevOps lifecycle and overall release processes, it could take minutes to weeks from a ‘Done’ ticket to make it to production. The longer that gap of time, the less your stakeholders will feel like you’ve improved predictability. The excitement shown during that sprint review when you demoed a feature on http://localhost:8000 will quickly turn to frustration when your stakeholders login to production and don’t see what you just demoed. If you show the what, without a clear answer for the when, predictability still suffers.

5. Lack of team fungibility

A key difference between agile and waterfall is that your main unit of capacity is the team rather than the individual. You know you have this challenge if, during a quarterly planning session, someone has said, “This is what we wish we could work on, but all of our teams are specialized to only work on other things.” The less fungibility that exists on your agile teams, the more difficult it will be to predictably deliver on your strategic goals. Rather than bringing the most valuable work to your teams, your teams will be telling you how busy they are on other stuff to work on anything else. Bold leadership is needed to make your functional organization act more cross-functional.

6. Overly customized tools

Tools and their setup can enhance or hinder your productivity. All too often, tool configuration becomes one of the biggest sources of conflict and tension on teams. If your team spends more time and shows more passion for tool configuration than your commercial product - the tool is in your way. We talk to many companies that admit their Jira setup has gotten out of control, but they don’t have time to fix it. We cannot overstate the impact of this on your teams. Every day, your engineers, scrum masters, and product owners are wasting time and getting frustrated that they have to fill out 20 required fields that no one cares about to transition a ticket through a workflow. They may hide it from you, but the number of hoops they need to jump through means they’ll just stop updating them - really hurting your ability to predict when features will be delivered.

See our 5 Jira Tips to Improve Transparency and Predictability post for some best practices.

Hakkiri Helps You Deliver Software Predictably™

Hakkiri empowers software organizations with our Continuous Clarity Engine™ to deliver products with speed and predictability. Our platform’s deep analytics surface insights that go to the core of what limits the ability to predict the completion of software deliverables. We know these problems because we’ve faced them and solved them. Stay tuned to our blog as we delve more into this space. In the meantime, check out our product page to learn more on how our platform can help you.

Robert Orefice

Written by Robert Orefice

Robert Orefice is the Chief Product Officer and Co-Founder of Hakkiri. He has previously served in senior leadership roles across Technology, Product and Portfolio/Program Management at Eze Software Group, WebMD and Aetion. In each of these roles he has directed Agile transformations with an emphasis on blending the right mix of tools and processes to drive a great team culture, while also giving the necessary visibility to executive stakeholders. Previous to his work in the software industry, Robert spent over 12 years as a microprocessor design engineer and methodology lead at Advanced Micro Devices (AMD). The process discipline, iterative engineering workflows, and demanding quality requirements from the semiconductor industry have enabled him to bring a unique perspective into Agile software development.