Increasing Enterprise-Level Predictability With Agile
We typically think of Agility as being nearly synonymous with adaptability, and that a change in mindset or culture to become more adaptable is the right place to begin Agile Transformation. But the truth is that one of the most common goals organizations have for Transformation is actually predictability. Why? Because it brings the organization the business results and outcomes executives want to see to make the business grow and succeed.
Yet while executives ask for predictable results and outcomes, Agilists tend to think you can’t get predictable while being Agile. But you can. And also, you should if you want to pursue organizational Agility.
Predictability is ultimately about figuring out how to make and meet commitments and do what you say you’re going to do so that the organization becomes a reliable trustworthy partner of the executives. And once you build the trust that predictability brings, it becomes far easier to prove the worth of Agile Transformation—and get more executive support for continued Transformation.
While predictability always begins at the team level, enterprise-level predictability comes with an entirely different class of problems to overcome and therefore requires an entirely different strategy to be achieved.
How Much Predictability Do We Need?
Different organizations have different needs for predictability. While some will need the most possible, others won’t need any at all. If you’re an organization that needs predictability 3-6 months out, or a year or more roadmap, this blog, and it’s accompanying position paper where we dive deeper into all of these topics, is for you.
The 3 Things You Need for Team-Level Predictability
Complete, Cross-Functional Teams
Making and meeting commitments to become predictable begins at the team level with complete, cross-functional teams. A complete cross-functional team is a group of six to eight people, give or take a few, who have everyone and everything necessary to be able to deliver a working, tested product or increment of software as described by the backlog.
Backlogs
The complete cross-functional teams need to work against a known backlog, a stack ranked list of things the teams are going to build, including user stories.
Getting to a Working, Tested Product
Once the team understands the size of the backlog and has a stable velocity, then the team can figure out how many sprints it will take to get through the backlog, or how much backlog they can do in a predetermined number of sprints. With all of these factors in place, they can then reliably make and meet commitments to produce a working, tested product.
Obstacles to Predictability
Dependencies
The reality is, not everyone starts out with a team that has everyone and everything necessary for it to deliver a working tested increment of product or software as described by the backlog. But without this, you will immediately have dependencies on your hands. If you have to depend on another team or outside resources to be able to deliver, you’re not going to be able to be predictable. Dependencies are the number one killer of Agility.
To overcome dependencies, you have to create the conditions you need in order to be predictable.
Backlog Problems
On some very typical Agile teams, the product is built and supported and the build side is predictable. Maybe user stories, estimation, release planning, and stabilizing velocity all work great. You’re mixing a determinate backlog with an indeterminate backlog, and some of the backlog is interrupt-driven.
Anytime you mix a determinate backlog with an indeterminate backlog, you’re going to have to deploy buffering strategies between the two, and while that’s possible, it can be complicated.
Predictability at Scale
The 3 Things at Scale: Structure, Governance, and Metrics
Even though this all boils down to the same 3 Things concepts from the team-level; teams, backlogs, and working tested software— as we start to scale, there are slightly different classes of problems and obstacles to predictability, so the focus of each shifts slightly.
Structure
Instead of focusing specifically on teams, at scale we must focus on the structure of the teams we have, and the way multiple teams relate to one another.
Governance
Instead of backlogs, at scale we focus on governance: the flow of work across the organization which supports our ability to accomplish business goals over time.
Metrics
While we produce working tested increments of software, at scale we add a focus on measuring value across multiple teams using metrics.
Team Level Agility is Insufficient for Enterprise Level Agility
Most organizations are projectized, and approve dollars for projects, and then deploy people into projects and form teams made by slicing people and teams into little bits to make them fit into the project metaphor to execute on a project. Those teams end up having a lot of dependencies. And dependencies kill Agility.
What if instead, we broke the project into pieces to be able to send those components to the right team to do the parts they are best suited for? Typically, we then end up with teams that have way too much on their plate, and teams that have very little to do and are starved.
This is a tricky situation because it’s not a problem of prioritization, or dependency management, or even a making- and- meeting- commitments problem. It is that you will simply never get high enough in the queue to get the attention of the constrained teams that are producing all the work that has the highest business value.
This is why we have to go back and create balance at the Portfolio level. To be predictable across the enterprise, what you need is an ability to look at the portfolio of work that’s coming in organizationally and make some guesses and assumptions and establish constraints that assert that the organization, based on the predictable, reliable delivery and performance capacity of individual Scrum teams, can start making bets about what the organization is capable of delivering.
Closing Thoughts
A predictable Agile enterprise demands predictable teams or else nothing else works.
You can be predictable and perfect at the team level and the organization can see no predictability and value at the enterprise level because you didn’t create structures to make sure the system is being fed in a way that funnels through properly.
Predictability is important and builds trust, both within the organization and for executives. Executives want it and they’re willing to pay for it. And once you show them how Agile is solving the problems they want to solve, like predictability, and the things you need to do to get it, you can make a strong case for Transformation.
We recently published a position paper on this topic. It’s called: Open the Door to Enterprise-Level Transformation By Increasing Predictability
In the paper, we discuss what it takes to adopt Agile, but through the lens of improving predictability. We do a deeper dive into the concepts we touched upon in this blog, and explore what’s required for team-level predictability, how to get there and then scale up for enterprise-level predictability, anti-patterns that prevent both team-level and enterprise-level predictability, what to do about them, and more.
Check it out here.