Often when I’m talking to clients about Lean software development, I find myself talking in very abstract terms, contrasting hypothetical cars and hypothetical bikes. Over time, I've realized my clients (and I) need concrete examples of how different development strategies can affect the success of a product — and I've finally found the perfect examples. But before we dive in, let me introduce two classic development strategies that I'll be referencing in the rest of this article.
Lean development takes the principles of the Toyota Production System (TPS) and applies them to software development. The TPS is based on seven principles of waste management, and they map well onto software development. Lean development helps engineering teams get value to customers quickly, which helps them de-risk feature development and keep up with market demands. This development strategy is closely related to an iterative approach to shipping software.
Lean development is often contrasted with Waterfall development, which separates the development cycle into linear steps. The team must complete each step (research, requirements, design, development, testing, etc.) before it can start the next one. This means that the target customer won’t get anything until the whole product is done.
Okay, okay — there I go talking in abstract terms again. Let’s bring it back down to earth by going to a galaxy far far away....
*Cue John Williams’s brilliant score*
Case study 1: the first Death Star
In Star Wars Episode IV: A New Hope, the galaxy was introduced to the greatest battle station ever seen: the Death Star. When it first appeared on screen it was fully functional and feature-rich, despite having its most important feature (the Superlaser) not fully tested. In Rogue One, two small feature tests occur, but only because direct market competitors (the Rebels) forced their hands at the planets of Scariff and Jedha.
The unveiling of the greatest superweapon in the galaxy illustrated both the great advantages and great drawbacks of Waterfall development. This monolithic battle station was certainly formidable and very polished (inside and out!), and made the Empire look very professional. It also was highly effective: it literally (and physically) destroyed the competition, and allowed the Emperor to make political moves very shortly after launch.
However, this style of development has drawbacks. All it took was one tiny bug — a flaw in an exhaust port - for the competition to send the Empire back to square one, annihilating all their work. Twenty-two galactic standard years of work from some of the greatest minds in the Empire, all gone because no one found the flaw.
If the Rebels had found and exploited the bug earlier in the Death Star's life cycle, the Empire would have lost less. Waterfall development is inherently more risky than Lean development, because there is time, energy, and money sunk into a product that can’t get market feedback until it is released.
Luckily for the Empire, they took a more Lean approach for the second go-around!
Case study 2: the second Death Star
Lean development is great at de-risking. By releasing features early and often, a team can quickly receive feedback from their target demographics. When they approached building the second Death Star, the Empire adopted a YAGNI (you ain't gonna need it) approach and built core functionality (including the Superlaser and the Throne Room) first, far ahead of less important functionality (like the outer shell).They even went so far as to outsource some of their security concerns (the shield generator) to a neighboring moon.
They were so successful in delivering the core value that the station was declared to be “operational” by a key stakeholder of a direct market competitor (Lando Calrissian, of the Rebel Alliance). Despite literal holes in the design, since the core value-driving feature was in place, the Death Star II was ready to crush (or blow up) the competition!
This kind of iterative development also decreases the time it takes to get to market. Despite the second Death Star’s being almost twice as large as its predecessor, the MVP showcased in Return of The Jedi was built and released in just four years. A Lean mentality allowed them not only to focus on building the core value-drive, but also to iterate on them. The engineers shortened the reloading time of the Superlaser from almost 24 hours to just under three minutes. Talk about continuous improvement!
What can we learn?
Now, back to Earth and the present day. I think we can learn something from the way the Galactic Empire was able to iterate and learn from their mistakes. I would like to think that we can learn to embrace and expect market change at least as well as such a far-reaching/monolithic organization as the Galactic Empire.
You may be saying, “Hey wait! The second Death Star blew up! Their Lean approach allowed the Rebels to win!” This is fair. However, I would argue that you can’t blame the Empire for the collapse of a key integration (the shield generator) and the betrayal of a key stakeholder (Darth Vader). There are some things that Lean thinking can't save you from…. like being evil! 😉
I hope you’ve enjoyed this case study of Lean versus Waterfall development, as demonstrated by the Galactic Empire’s development of the two Death Stars. Happy May the Fourth!
Aaron Foster Breilyn (afb)
