After 20 years of Agile, I realize that I fell into the trap of believing that with Agile, the customer has to pick just one: a fixed date or a fixed scope. This belief is misleading and only partially true. What I realized yesterday is how you can deliver a fixed date, fixed scope project with Agile.
Agile Myth: Scope or Date?
Agile works from the assumption that there is a fixed team that is working on a problem with a fixed velocity (or work capability). Under these constraints, the customer can choose: Fixed date with variable scope Or Fixed scope with variable date On the surface, it seems like this is just the constraint of reality. And fixed scope, fixed dates that the business or customer requests seems impossible.
Or is it?
Team – Investigate the Assumptions
When we pause and look at the bigger picture, we can begin to question our assumptions and assumed constraints. Here’s what to do:
- Investigate Scope
At the beginning of a project, there is so much complexity and unknown that teams are just taking an expert guess at scope and effort. The Agile way is to have a shared conversation to explore what really needs to be done and what might happen later. Also, it’s useful to question what level of solution is needed; why build a highway when you only need a footpath? - Investigate Solution
Give teams time to investigate solution options and technology to de-risk the project. This will reduce uncertainty and clarify timelines. - Investigate the Team
All the estimates given by the team for completing the work are based on their current skill level and capabilities. The question to ask is: what skills and capabilities do we need to deliver the project sooner? Most teams are not learning rapidly and have never experimented with huge productivity-boosting practices such as pair programming. As such, there is usually space for the team to improve to the point where an impossible project becomes possible. One graduate of our leadership program reduced a project from three years to less than one year by focusing his team on learning. Read more here.
If you want to get a deeper understanding of how Agile is supposed to work and how to solve for these challenges, please check out the world’s best overview of Agile is here: Henrik Kniberg’s Product Owner in a Nutshell.
Leadership – Change the Equation
One huge blind spot for Agile is that it made the mistake of getting rid of all the managers. When we look at the problem from a management perspective, we see that there are many options that are available.
- Free Up Capacity
To make space and time for the big fixed scope/date project, we can have the team cancel other projects and deliverables that have lower priority. Note: don’t give away bug fixes and production support because you’ll end up with one team creating bugs and another one fixing them. This is bad for morale. - Add Additional Existing Teams
Most organizations have multiple teams. The possible fix here is to add one or more additional teams to give the extra effort needed. The caution here is that extra effort will be needed to keep the teams in sync. - Add Additional Talent
People deliver projects. Maybe it’s time to add some talent to your existing team. Find out what role is the bottleneck for delivery and add someone there. The caveat here is Luke Hohmann’s rule: “More than 8, no collaborate.” - Create a New Team
The final option is to create a new team. The caveat here is that each new hire will initially slow down delivery. Even with rapid learning and pairing, it can take a month or more before a team will recover from the costs of interviewing, orienting, onboarding, training, and mentoring.
The Fear Trap
It’s normal, appropriate and healthy for Product Owners and Management to ask the question: What can we do to deliver this earlier? The most common misinterpretation and reaction from team members is to think that they are being pressured to deliver a project sooner than is possible. As human beings most of us have been conditioned from a very young age to comply with authority (starting with parents, then teachers) so we falsely believe this is what is happening. The second aspect is that software development has a long history of cutting quality to hit the date which results in technical debt and impairs future delivery. The obvious solution is for all of us to come together to solve the business need to investigate both team level options and leadership options.
Leaders Determine Safety Levels
It’s up to leadership to create an environment where people feel safe to ask questions and learn. It’s even more important to establish enough trust and goodwill that people know they are not being asked to create a death-march project. What we find in our leadership training is that most leaders need to develop new skills to support a high-safety environment, especially with remote working. Read more on creating Safety and safety for remote teams.
Working with Waterfall Project Teams
As Agile is about flexibility and doing what makes sense, there is no problem to interface and interlock with Waterfall project teams and reporting requirements. The main problem to overcome is that people feel frustrated with the “extra work” needed to deliver. The fact is that these bits of extra work are like “organizational user stories” that need to be accomplished. In fact, when you look at history, the Gantt Chart was created to get congress off the backs of the people leading the Trident nuclear submarine program. The secret is to have innovation on the inside and traditional reporting on the outside. Please the “culture bubbles” in our book leading beyond change for a more detailed explanation.
How Can We Honestly Make Commitments When We Don’t Know?
In the best case, there is time and budget for the team to have a discovery phase to investigate and de-risk the project as described above. The discovered information can be used to ensure adequate capability to meet the demand.
Sometimes it is the case that commitments need partial and incomplete information. It is normal for complex projects to have insufficient information. The solution is to make a best guess as a group. This could be supported by stories and estimates or based on industry experience. Many traditional workplaces do not value the truth and project teams play a game of “chicken” to see who will take the blame for being late. If this is your environment, then it’s important to play the game as best as you can while at the same time building the actual collaboration needed for successful delivery.
Fixed Scope and Fixed Date is Usually Feasible
While there are, of course, some impossible projects, most projects are completely feasible when we keep an open mind and investigate all possible options. The first and best option is to work with the team to investigate assumptions and learn together with the business what is possible and what the trade-offs are. The second option is to change the equation to increase delivery capacity. Of course all of this depends on a culture of safety and trust where people can work shoulder to shoulder on finding the best path possible.
