Agile coach and guru against his will, Henrik Kniberg has advised some of the most innovative companies around the world, such as Spotify and Lego. Invited as a speaker at USI 2017, he shares his findings and beliefs on agile methods in front of a captivated audience.
What started as a new magic potion to making software development more efficient has now spread to all the different areas of a company: HR, education, contracting, project management, etc. How can we explain this craze for agile? And can agile be the silver-bullet for every organization?
The shift from waterfall to agile
For years, software development has used a methodology called “the Waterfall model”. The common approach was:
- A client has a problem to solve.
- The requirement team analyzes the problem, writes a synthesis and passes it to the design team,
- the design team analyzes how to design the product, writes another document and sends it to the developers team,
- the developers write the code and send it to the test team,
- the test team evaluates the code, solves the bugs, and delivers the product to the client…
- … and most of the time the client is unhappy.
Indeed, this model tends to face misunderstandings along the process and suffers from an overlong feedback loop. As a result, however beautiful the code may be, a lot of projects end up being giant failures: nothing is delivered, or the project is delivered and doesn’t work, or the budget is overrun… The reason behind this lies in three assumptions: customers know what they need, teams know how to do it, and nothing changes along the way. What used to be true in simple and inherently predictable domains doesn’t work anymore in complex and changing environments. It’s the very reason why teams need an adaptive process.
The very beginning of agile methodologies starts with getting rid of the silos in organizations and instead creating cross-functional teams. Rather than building the whole product at once, this cross-functional team builds part of the product, delivers it and gets a partial feedback that then helps them adjust and deliver a bit more, etc. Gradually, the product gets closer to the customer’s needs, and the customer becomes happier and happier. Agile projects don’t always succeed, but when they fail, they fail faster, hence more cheaply.
The hegemony of agile methods
Why is agile spreading so fast? Why does it work so well? Or doesn’t work in some cases?
According to Henrik Kniberg, organizations are riddled with waste. “Most of what you do and see in the workplace is waste”: products that people don’t use, features that people don’t need, meetings that don’t add value, documents that employees don’t need… Agile methods give team members the opportunity to question the status quo in order to focus on the essential. Domains that are inherently predictable – projects that are clear, stable, simple, and that the team knows how to do – don’t really need agile. A classic methodology can be sufficient, and will probably be more efficient even. And even predictable with some degree of complexity just need a little bit more planning.
Agile methods really strive in complex domains, in which customer needs and unclear and evolve over time, solutions are unclear and technology changes. That’s where agile is optimized for. In these types of situation or project, one shouldn’t bother aiming too much, but rather get the project started in the right direction, and then adapt – like a homing missile. And as the world is getting faster, more complex, more interconnected, companies increasingly need agile. Indeed, agile accelerates product delivery, enhances their ability to manage changing priorities and increases productivity. Agile is spreading because companies want to be able to compete. And it’s not only for software development: it spreads like a virus between departments (HR, procurement, …).
“Agile methods give team members the opportunity to question the status quo in order to focus on the essential.”
Diving into the depth of agile
Scrum, eXtreme Programming, and Kanban are three different toolkits, three different flavors of agile, like the branches of a tree which trunk would be lean and agile principles. In this allegory, the roots would be a mix of systems thinking, complex adaptive systems, psychology and queuing theory.
Instead of focusing on effort (such as the number of hours of work, time report or resource utilization) like in traditional organizations, Scrum, XP, and Kanban methods concentrate on output, each having their own priorities:
- Kanban focuses on cycle time and how long it takes for an item to get released.
- Scrum optimizes for velocity (the number of tasks done per weekly sprint)
- XP also monitors velocity through the “Load Factor” (the ratio between ideal engineering days and calendar days) and the progress of the Functional Test suite score (the number of functional tests written by the customer that are correct each week)
With all their specificities, Kanban, Scrum, and XP share the same lean and agile principles:
- Work in small, stable, cross-functional, self-organized, co-located teams
- Release often and get real user feedback
- Experiment a lot with product & process
- Focus on value (customer satisfaction, profit) and learning
With these methods, more and more agile companies win market shares over the big slow organizations, that become desperate for change. But agile is not a silver bullet, and as it becomes more mainstream, its differentiator factor fades away. Today, if the IT sector is already flooded, agile is still in the early adoption stage for other departments. Henrik Kniberg predicts that in the next 10 years, the world’s complexity will keep increasing and change will happen faster. The agile approach will be considered obvious but new and different frameworks will appear. Finally, agile methods will keep spreading to different industries, and organizations that don’t succeed in becoming agile will die.