What is the definition of Predictability?
A consistent repetition of a state, course of action, behavior, or the like, making it possible to know in advance what to expect.
Ultimately all project teams get asked a pretty simple sounding question – When will it be Done?
We make investments in software development with the express purpose of delivering some new capabilities to the organization, either new Features on our website for our customers or new efficiencies designed to save money on the bottom line.
Predictability is probably one of the more contentious topics of conversation in Agile because for Agile Teams Predictability isn’t about being able to tell you when something might be done.It’s about conveying to the organization that your teams have a level of maturity in delivering software every two weeks over predicting when a 9-month project will be complete.
Business Agility – The Holy Grail?
As Agile is evolved in organizations we’ve come to understand that the Technology transformations that we are most familiar with aren’t addressing the broader organizational needs. Getting technology Agile doesn’t deliver value if the rest of your business doesn’t also change.
Enter – Business Agility.
Business Agility is the answer to a problem we didn’t know we had. Business Agility is the flip side of Technical Agility and when we bring the two together we get this:
For us to reach a high level of Agile maturity we need high levels of Accountability between our Business and Technical organizations.
All too often there is a substantial amount of distrust between our Business and Technology leadership.
In my years of working in and coaching with organizations I’ve observed the following:
1. Technology believed that Business didn’t know what they wanted nor knew what was valuable and Business had abdicated their role in driving value decision making.
2. Business told Technology how to develop what they wanted to the point that Technology abdicated their role as Technology experts, resulting in a set of systems that were virtually unmanageable.
3. Technology unable to make estimates that were close too realistic, with project overruns happening for over 70% of their projects. Even with the PMO padding estimates Technology somehow in the Business opinion found a way to exceed even the most heavily padded estimates.
In order to develop Business Agility, the organization must first address the underlying trust issues that exist in the organization.
You must apply TAP to your entire organization.
What does this look like?
1. Training - As mentioned in the Transparency chapter, everyone must go through training, everyone must learn the language of Agile and the language and behaviors with respect to whatever framework you end up choosing.
a. Language – Everyone must first learn the language of Agile, Scrum, SAFe, etc. Most organizations don’t train everyone; don’t make this mistake it is key to the high levels of awareness that must exist to achieve organizational Agility.
2. Cross Organizational Coalition – This is key as we must engage the entire organization as we discuss and agree to the necessary changes both at the organizational level and down into the operational level.
3. Strategy – You must have both clear Business and Technology strategies that your Agile Vision and Mission must align to. Your Product and Technology roadmaps must be in sync. At one organization they lacked a Technology roadmap which ultimately couldn’t be developed until it was clear both where the business was going and what they were willing to invest in.
Being transparent about where you are at in an organization is fraught with peril as we are exposing not just the ineffective or inefficient elements of your organization we are also exposing people who may or may not be directly to blame for the organizational inefficiencies.
What does that look like?
1. Planning - People who do the work Plan the work – Work cannot be estimated by managers, Tech leads who aren’t going to be directly involved with delivering the work.
2. MVP – Focus on delivering small valuable pieces of work over big bang delivery. Being accountable for smaller deliveries is much easier over long running death march projects.
3. Reporting – Leveraging your tools for tracking work to establish fact based reporting. Reporting should be part of lightweight governance so that we establish a means to indicate when the business has shifted their focus to include more scope in the MVP or technology has uncovered significant challenges with the current direction of the development approach.
4. Decision Making – Teams are better at being accountable when the organization delivers fast turnaround with respect to decision making. You need to empower people at lower levels to make decisions and remove the need for ever higher escalations on decisions for something that might be 2 days’ worth of effort by the team.
5. Failure – Understand that with building strong levels of accountability you need to provide space to teams to fail. Meaning when they try something new that they think might help them work better they might actually fail to deliver something due to the attempt to change. Celebrate failure, not for the fail but for the attempt.
What does that look like?
1. Consistent Results – Look for teams to deliver consistently with whatever mechanism you choose to evaluate delivery performance, such as Story points, # of stories, Value points, etc.… The objective is to establish a platform to visualize how teams are performing.
2. Roadmaps – Without a clear and consistent view of what the organization is attempting to do at the product level, teams won’t have the ability to deliver high levels of predictability due to ever changes decisions on direction. Agile is not a free check for change, that leads to chaos. And unlike Stephen Hawking’s book ‘A Brief History in Time’ where he established the premise that there is order in chaos in physics, that premise sure doesn’t translate to human based systems.
3. Planning Discovery – For larger product development efforts be sure to provide time for teams to have Discovery sessions where you bring everyone who can provide context to what we want to develop. This means bringing in UX, Developers, QA, Business Experts, PO, etc. for a specific length of time (from a couple of days to a couple of weeks) to build a Product backlog that the team can begin working from. There will be those that say this is a waste of time but my experience tells me otherwise, especially if the large effort you are about to begin already has an end date associated with it. Asking teams to be accountable for this without having time to discuss the roadmap ensure that we won’t be predictable in our delivery.