In his paper "No Silver Bullet — Essence and Accidents of Software Engineering,” Fred Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." Brooks, a Turing Award winner and the author who also brought us “The Mythical Man-Month: Essays on Software Engineering,” also states that "we cannot expect ever to see two-fold gains every two years" in software development, like there is in hardware development (Moore's law). In other words, there is no silver bullet.
Daily Stand Up Credit: Huddled, Drew Bates https://flic.kr/p/9bSAba
Over the past two decades, we’ve seen companies embrace Agile development and Lean methods as their silver bullet. Agile and Lean both promote evolutionary development and encourage fast and flexible response to change. They systematically seek to achieve large scale benefits from a repeated cycle of incremental changes. Both provide a toolbox to improve execution at the micro scale.
Agile methods promote the idea of team-scale self organization, which is fine at that level. Lean is especially good at uncovering problems that cross multiple value chains.
To the extent that both Agile and Lean help an organization just get better at "getting things done," they will absolutely drive improvements.
But while both of these have a vital role to play, neither offers a complete solution. Agile won’t help you with the structure of your business as a whole. And when implementing Lean, the more optimal you make it, the harder it is to change. Neither of them offers tools to make the organization more capable of withstanding failure— becoming antifragile.
Agile development arrived on the scene as a response to the heavyweight methodologies of the 90s, when every software development method had turned into a stack of document templates. Template zombies reduced any process down to a set of document templates – essentially eating the brains of the process.
As conceived by its creators, the entire premise of agile development was that its focus should be to deliver running software and continually improve it. Any focus that did not deliver running software to the customer should be eliminated. Somehow along the way, Agile got redefined by the weight of the majority opinion's misconception. The first misconception is that Agile is a project management methodology. It’s not. The second is that you can use a tool such as Scrum with all it certifications, rebrand your project managers as Scrum Masters, and you are agile. You’re not.
If every team in your company is doing the same thing, you are not "big-A" agile or "little-a" agile. Instead, every team should be evolving its own way of working. When you are truly agile you can change your direction very quickly—you can redirect individual teams and what they’re building very quickly. Still, even if you are doing that really well and delivering software with value, you’re may not be achieving antifragility.
Remember Blockbuster Video? They offer a great example. Blockbuster had plenty of internally developed software to track inventory and manage customers. They probably had a whole team devoted to calculating late fees. Each of those software teams could be wonderfully agile on their own. Did that make Blockbuster as a whole agile? Or antifragile? No. In Taleb's metaphor, the switch to online streaming was a black swan event. Every team at Blockbuster could be agile, but the organization as a whole lacked the ability to respond to this once-in-a-lifetime shift in the marketplace.
Agile development can be effective at the team level and still not contribute to antifragility. Antifragility must be a property of the organization as a whole.
When an organization begins a lean initiative, odds are they have ton of problems and a ton of inventory or unfinished work gumming up the process. Here’s a hypothetical example to demonstrate the limitations of lean.
Let’s say you publish a monthly magazine. Each issue has a production cycle of 12 weeks, and at any given time you have multiple issues (inventory) in the works, each at a different stage in their production queue—from editorial calendar to content development, layout and design, printing and distribution.
You need to track the status of all the issues and continually update them as they wait in the production queue. Along the way, a cover story changes due to breaking news, a photo needs to be reshot, an editor quits, a key interview falls through, an issue is late to press due to production problems, mailing costs rise and you need to research new vendors.
There’s a lot of cost involved in carrying that much inventory and a high risk of waste. Applying lean principles, the first step says that you would take that 12 weeks and reduce it down to 4. Starting the process, you look for all the things that take too long, solve those problems, and bring the cycle time down, which will reduce the amount of work in flight and eliminate tons of costs and waste. That’s impressive.
But not so fast. In these early days of your lean initiative you may reduce inventory and in fact get an improvement in productivity and increase profits. But something starts to happen after that. Taiichi Ohno, creator of the Toyota production system, provides this analogy to lean process: it’s like lowering the level of water in the river so you can see the rocks. You find the rocks and take them out of the river. Then you lower the water some more…
I think this is what happens: the more you lower the water or reduce inventory, the more you start to build infrastructure to make the way you are doing things go faster. You shift from removing waste and shortening cycle time to shortening cycle time by increasing automation and increasing the specialization of what you are doing.
A Japanese car manufacturer gives us a good example of this phenomenon. The automaker found that they could improve cycle time on the production line by building a rig that is positioned inside of the car. The rig turned the car as it goes through various steps rather than moving along on a belt. The carmaker was able to introduce this method rather quickly, which reduced the production space needed. That’s the upside. On the downside, with a rig designed to fit a specific type of vehicle, it became much more difficult to modify the design of the vehicle, or switch over from production of cars to vans or trucks. There was a trade off between efficiency and flexibility.
Here’s another way to look at the trade off between efficiency and flexibility. If you travel in small sailboat, you have the flexibility to stop at any sand bar you like. If you’re steering a cruise ship, you can only stop at deep water terminals that have the capacity to handle a vessel of your size, for example a sufficiently strong dockside infrastructure, mooring lines and gangways to reach the height of the vessel. The cruise ship is vastly more efficient at moving people around, but far less flexible because you can’t change your destination nearly as easily.
Agile and Lean promise to deliver incremental improvements, and they do. Both have been important developments. Agile is necessary but not sufficient, Lean is good but too much of it will make you fragile. I opened this post with a quote from Fred Brooks, whose silver bullet was all about productivity and efficiency. If we actually found his silver bullet we’d be doing exactly what we’re doing now, just more efficiently. We’d be even less resilient. The silver bullet we’re seeking needs to move us towards continuous delivery and DevOps, which will open the doors to antifragility.
Read all of Michael Nygard's The New Normal series here.