Agile teams are resistant to commitments. This makes stakeholder management hard.
As product managers, one of our most crucial skills is the ability to navigate and meet the expectations and commitments of stakeholders.
It's an essential part of our responsibility to ensure successful product delivery. Building trust and confidence with our business stakeholders unlocks endless possibilities!
In this guide, we will explore the purpose of commitments and then look at the types of commitments.
We will also look at what the role of a product manager is in the process and how to represent commitments to manage stakeholder expectations.
I will also delve into the challenges faced by Agile teams when it comes to making commitments and how to overcome them. Many Agile practitioners are not fond of commitments. However, being vague doesn't help manage stakeholders' expectations so we must have a way of managing this.
The Agile cargo cult challenge
"In most Agile teams, when you even mention the word "commitments", you get reactions ranging from squirming to denial." - Â from the book Inspired by Marty Cagan.
It can be quite a challenge given some of the work the Agile cargo cult has had on people's minds about making commitments and visualizing them.
My story with GANTTs began, early on in my life at the age of 15, while working on construction projects in my parent's company where I created detailed schedules and tracked dependencies across massive programs of work.
Later in my career when managing a PMO - project management office, I was responsible for looking at expectations across larger portfolios. Â
Even with all these years of doing this stuff, I am personally not a fan of GANTTs.
But hey I am not alone, Agile folks are also
not a fan of commitments.
They prefer to be vague
(intentionally or unintentionally)
but that doesn't help manage
stakeholders' expectations.
When I got into management roles, I realized the importance of planning and expectation management which is something I couldn't phantom as an individual contributor. I then also understood the various ways and alternatives to manage expectations rather than being forced to do GANTTs.
Did you know that GANTTs are a World War 1 artifact, later used in waterfall project management?
Agile rebranded this to "roadmaps".
Commitments are required for 3 major reasons:
There is a massive industrial complex behind this (eg: JIRA and Agile Delivery Managers) and the practices are deep-rooted in organizations. How do you manage the Agile fanatics then?
The key is to explain to a team that it's not about estimations or project managing them.
Managing expectations helps drive business outcomes through a planning process.
- Alignment on prioritization of efforts
Businesses have multiple departments, functions, and people. To align everyone to focus on a particular effort requires some planning.
This requires an agreement on priority which can come from effort analysis and estimation process which gives a business an understanding of when something will happen. - The highest business value items are the focus
Business leaders want to ensure that the teams they manage are working on the highest-value items to ensure they are profitable and meet business objectives.
If they understand that something takes longer then maybe they might another decision. - Partnership/ business agreements require date-based commitments
Every business has agreements with other businesses which quite often require time-based commitments.
It is almost impossible to build a partnership without this commitment.
TLDR;
Business plans and strategic partnerships are made around delivery dates. This is where determining if an organization should commit to a specific build timeline is important. If not the leadership team can prioritize something easier or commit to a strategic partner at a later date.
Types of commitments
There are 3 main types of commitments and they are based on predictability and confidence that a product manager must communicate to the management team and stakeholders.
Pro Tip: Confidence levels are important to understand and communicate. They should be made explicit and not assumed. (ie: Spell it out that something will probably be 40% probable, it will help people decide if they want to invest in something or change and explore other options).
- High integrity commitments
These commitments are where the confidence levels of the product team and product manager are high at 80-90% to deliver on time, based on a clear understanding of the challenges involved and what needs to be delivered.
It's normally important for a product manager to explore the risks and options available here to deliver on this type of commitment.
To get to this type of commitment, it is important to spend time on discovery efforts and validate the solution space to minimize schedule risks caused due to uncertainty in technology development. - Roofshots
Initiatives with 60-80% confidence levels on delivery and there is a risk that it's still something that could blow out by a margin of 20 - 40% due to dependencies, lack of time on discovery, and unknown effort for recovery.
Pro Tip: When presenting the roofshots a product manager must have some options available to ensure that stakeholders can decide on if they want to progress with that option or go for something with higher confidence levels. - Moonshots
These are typically R&D initiatives with very high unpredictability.
They are the sort of high-reward high-risk initiatives most of the time but maybe high risk and low reward.
They may also lead to businesses making massive losses and going bankrupt or having to shut down business units.
A product manager must understand that confidence in anything below 50% is a moonshot.
Pro Tip: As with roofshots, the product manager should come up with some options for the stakeholders to make decisions.
The product leaders should understand the risk involved here before agreeing to go down the pathway.
Impact of technical debt
Quite often in the world of technical debt in software, product managers might find themselves in a tough spot with some very easy initiatives being moonshots simply because of the tech debt.
In these circumstances, it is critical that the PM calls out the reasons for low confidence and explains why it is a Moonshot that must be addressed.
The role of the product manager in expectation management
- Confidence rating framework
Have a confidence rating framework and set high confidence for the ones with assurance on delivery date. - Discovery
If the confidence is low ask for more time on discovery to determine options and risks. - Communicate
Over-communicate, it is always safer to over-communicate than under-communicate. - Checkpoints
Regular checkpoints and updates on progress are super critical to keeping things on track. - Celebrate
Celebrate wins! Celebrating helps build confidence and trust while also motivating teams. As a product manager, one of your key roles is to help build trust in the teams and stakeholders. You are the glue between the engineering & design teams and the rest of the business.
The curve balls to watch out for
- Dependencies
There are different types of dependencies, from another product team to a 3rd party vendor to a business partner.
It is important to keep a watchful eye on the dependencies and have regular checkpoints.
Don't forget to over-communicate on the progress of these dependencies. It helps drive trust and confidence. - Risks
As with dependencies, there are risks with different levels of impact and options to mitigate. Understanding and planning for these is critical. - The Resource Trap | Merge Hell
Brooks Law:
While on this topic, if we consider what Fred Brook said in 1975 about the observation he made on software project management, according to which "adding manpower to a late software project makes it later".
This he stated was due to ramp-up time, communication overhead & limited divisibility of software development work.
Funny enough, 40+ years after he came up with this theory, I experienced this on a project. A senior engineer I worked with, called the phenomenon of having too many engineers "Merge Hell".
This was on a team with 10 software engineers & 5 QA engineers on a single codebase on a product that was on a "project lifecycle" and 2 years behind its schedule not to mention a few million over budget!
It had CICD, microservices architecture, automated testing, and all the buzz you can think of from a technical standpoint - but the one thing it didn't have was good product management!
In my opinion and experience, to avoid delays and large amounts of technical debt, the perfect size and type of product teams per product stream should be from 7-8 individuals including analysts, designers, product managers & engineers.
In the next article, I will share various ways to present these commitments.
