(Want to get this article in your inbox? I publish one article a month and share it in my newsletter first. You can sign up here and join 40k other subscribers.)
Recently, I was at a dinner held for the speakers of a conference in Hamburg, Germany. The conference organiser, a consultant working on several government-driven initiatives, turned to me and asked “the question that dare not be asked,” “Why does every project have to be Agile these days?” He was frustrated that ways of working were being dictated by his clients without a concern for (a) his preferred (and proven) ways of working and (b) the challenges that “being agile” posed for government contractors. The truth is that these challenges are not limited to government contractors. Any service provider or team dealing with stakeholder requests is most likely being asked to work in an agile fashion. And forcing a specific way of working on a team simply because it’s “cool” or the flavour of the month is short-sighted at best.
I have to admit, it took me what felt like an eternity to respond. Like many of you, my default point of view is that Agile is better and, duh, why would you not want to work this way? But this question put me in a position to reflect. Is “Agile” really the best way of working for *every* initiative? Is it really a silver bullet for what’s ailing our delivery challenges? Despite 20+ years of experience I still didn’t feel qualified to answer with a definitive “yes” to this question perhaps mostly due to the fact that, even with my experience, I’ve not worked in every industry nor every situation.
After some deliberate thought (and two glasses of Chianti) I turned to him and said definitively, “No. Every project does not have to be Agile. However, each project you work on should encourage and support agility. This means that every initiative creates the ability, desire and safety to change course in the face of evidence that contradicts our original plan.”
What’s the difference?
When a project is declared an “Agile project” it is presumed the team will work in sprints, use some kind of board to track their work, have a scrum master and deliver shippable increments every two weeks. While I don’t disagree that this could be a productive process for a team, it is simply one permutation of agility. Instead of fixating on the specific recipe for how the team will work, I recommended to my new friend that teams should adopt the principles of agility. Agility, as I’ve noted here many times before, is, to quote the agile manifesto, responding to change over following a plan. Truly agile teams enjoy the ability, desire and safety to respond to change over following a plan. Let’s look at each one to see why it’s so important.
Ability — the ability to change course (i.e., to be agile) comes from self-sufficiency and empowerment. As a team is working through a challenging customer problem they may discover that some of their original assumptions are wrong. A self-sufficient team has all the skills it needs to adjust course regardless of what comes their way. This does not necessarily mean that there is a representative of every discipline on the team. It simply means that between the current team members they can cover all or the majority of the work that needs to be done to move the initiative forward. In addition, this team is empowered to make those course corrections without a lengthy approval process because they are closest to the tactical information about the initiative and these tactical decisions fall squarely within their wheelhouse.
Desire — It’s one thing to be able to make course corrections in the face of new evidence. It’s another to want to do it. You may be asking yourself, “Why wouldn’t a team want to make a better version of their product?” The answer is not that they don’t necessarily want to make a better version but that it’s not what they’re incentivised to do. Iterations and scope changes require explanations, plan revisions and managing stakeholders who may not look kindly upon these changes. A team that is worried more about the success of their customer rather than their stakeholder often has the desire to adjust course based on evidence. Teams fixated on meeting stakeholder deadlines and demands will often dismiss customer feedback and significantly reduce their agility.
Safety — Ability and desire to change course are worthless without safety. The more I work with executives the more I realise that this is the key facet of organisational agility required for the success of transformation initiatives. Let me be as clear and explicit as I can be: safety is the feeling a team has that the work they are doing and the decisions they are making will not result in negative impact on their employment status and standing in the company. If the team believes that making a significant pivot in the direction of their initiative will get them disciplined or fired, they will not take it. To be blunt, they will not be agile. Safety falls squarely on the shoulders of management and leadership. Creating a culture that values learning, evidence-based decision making and customer centricity creates the safety teams need to fuel their agility. Without this support teams will match their work to the initial plan regardless of what they’ve learned in the process of making the product.
Many processes and permutations of Agile can fit into the categories of evidence-based, customer-centric ways of working. In the end, these principles provide the conditions for agility to thrive. However, none of these processes nor the agility they hope to achieve will survive if teams don’t believe they have the power to make course corrections without the risk of executive backlash. To avoid this, it is incumbent on us to expose our Agile recipes for what they are — ways of working that bring us closer to the customer and provide the structure to adjust our planning in the face of newly discovered evidence.
Upcoming Events
Certified (Smart) Scrum Product Ownership Workshop with Jeff Patton – September 18-19, 2019 – Munich – Jeff Patton and I return to Europe this fall with our always popular 2-day course on blending Scrum, Product Management, UX and design into the ideal product ownership practice. This event always sells out early. Don’t wait.
Certified (Smart) Scrum Product Ownership Workshop with Jeff Patton – September 23-24, 2019 – London – Jeff Patton and I will also be in London the following week for this same class.
Professional Scrum with UX certified classes (scrum.org) are now rolled out worldwide. Check out the available classes in your area here.