Explaining Waterfall and Agile development with lasers and explosions.
It’s that time of year again, when families sit down to a holiday dinner to share good food, celebrate longstanding traditions, and ask that one distant relative seated next to them, “So…what is it you do, exactly?”
For a software developer working in an Agile environment, talking about Scrum meetings and story points and so forth isn’t really going to help answer that question, or explain why anyone would want to do things in a newfangled trendy way like that compared to Waterfall-style traditional business practices.
So, since a new Star Wars movie is upon us, here’s a handy metaphor from the galaxy far, far away to help explain to that second cousin once removed why Agile is the way to go.
The Scenario
Imagine that the Galactic Empire and the Rebel Alliance are companies.
The Empire would be a massive corporation, of course. It’s a Fortune 1 company — the only game in town, really — with a wide variety of business units covering everything from defense contracting to large-scale manufacturing to Military Occupation as a Service (MOaaS) solutions.
The Alliance, meanwhile, is a small startup with a mostly flat hierarchy, a very diverse employee base, and a large proportion of remote workers. They’re all about disrupting the industry, which in this case means disrupting the Empire.
The Empire has come up with a great new product that they think will let them stamp out any potential competitors — code-named the Death Star — while the Alliance hopes to develop a product that will render the Death Star obsolete before it even comes to market.
Waterfall: The Empire
Analysis Phase
The DS-1 Orbital Battle Station is designed by committee by a mid-size conglomerate, the Confederacy of Independent Systems. Satisfying all of the competing interests within the company is difficult: the Trade Federation wants everything to be run by droids while the Geonosians want it to be run by living employees, and the InterGalactic Banking Clan keeps derailing discussions to talk about financing. It takes years to hammer out all the fine details.
Design Phase
Once all the requirements are defined, design starts. Calculations are carried out, simulations are run, projections are made, and snazzy 3-D models of the end product are created to wow the investors.
This phase once again takes several years to complete for a project of this magnitude. Eventually, the final design is signed off by all the major stakeholders and it’s handed over to Engineering.
Development Phase
Initial development goes very well, but as in every project there are some major obstacles to overcome. Resources are allocated to different business units and staff are rotated to different teams to deal with some project delays elsewhere in the company.
Several years into the project, the Confederacy goes through a merger with another company, the Republic (or, well, it’s more of a hostile takeover, really). The Death Star project continues, but falls massively behind schedule as team members on both sides focus on knowledge transfer and the Republic engineers get to know the different technologies in use. Everyone works 16-hour days to catch back up to the schedule, and morale is low, but eventually things are back on track.
A few years later The Republic goes through a major re-branding effort to become The Empire. Work falls behind again, as the new Empire likes nothing more than bureaucracy (though stylish uniforms and fearsome starships are a close second) and engineering teams are overwhelmed with status reports, resource allocation meetings, and the like.
The design is two-companies-old at this point and its requirements as initially laid out don’t exactly match the Empire’s requirements, but it’s too late to change course at this point without even more delays.
(At some point in this process, a Quality Assurance engineer files a minor bug about a lack of shielding on thermal exhaust ports. There’s no time or budget for new features like that, though, so the bug is closed as Won’t Fix.)
User Acceptance Testing Phase
Twenty-some years after the project is started, an alpha test is conducted at the headquarters of a small company named Alderaan LLC. It goes very well.
The team goes out for drinks to celebrate, but when they get back to the office on Monday they hear that the Alliance is planning to beat them to market before their beta test at Alliance headquarters…
Agile: The Alliance
When the Alliance first hears about the Empire’s killer app, they have neither the time or the resources for a lengthy planning and design phase, so they take an Agile approach to the problem and start working in several-hour sprints to get the project done as soon as possible.
Sprint 1
The goal is defined: “Head-On Capital Ship Assault vs. Project Death Star, v0.0.1.” The basic design is sketched out on a holo-board, a few tasks are assigned, their product manager Leia Organa promises some competitor analysis at the next planning meeting, and Rebel engineers start researching.
Sprint 2
Leia is delayed coming back from an Empire-sponsored conference and the team doesn’t get the analysis they need. This isn’t great, but the team can adjust and re-prioritize their tasks to stay on schedule.
Sprint 3
The Alliance has a Minimum Viable Product, and upgrades their Death Star Assault plan to v0.1.0. Still no sign of Leia, unfortunately, but the MVP is modular enough that they can easily make changes based on her report before they demo the product to Alliance executives.
Sprint 4
Leia finally returns from the conference, having hitched a ride from some contractors. She brings along a new hire, Luke Skywalker, to help with the project and the team welcomes him and begins ramping him up.
Sprint 5
Leia announces that the plan has completely changed. Her analysis shows a major design flaw in Project Death Star that the Alliance can use to their advantage, so the team pivots to work on “Single Starfighter Assault vs. Project Death Star, v0.0.1.” Luke has some prior experience in this area from his work with Tattooine LLC, so he heads up the new effort.
Sprint 6
Delays, delays, delays…the Empire puts all sorts of obstacles in the team’s way, from threatening to sue for corporate espionage to hiring away Rebel engineers one by one until there’s only a handful of them left. The retrospective meeting at the end of this sprint is not a very happy one, but they’re still optimistic.
Sprint 7
Despite the many issues they ran into over the course of the project, the Alliance delivers the final product on time and under budget.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
Software Development In a Galaxy Far, Far Away was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
