How Agile Beat Godzilla

Written By: Colin McMahon
  • 9/6/2022
  • Read Time : 5 min
godzilla-agile-900

Understanding Agile product development can sound tricky. It’s a new way of thinking about collaboration, development, and business and general – spawned from the Agile Manifesto, a document designed solely for software development but as it turns out, it’s applicable to so much else. Many organizations, whether they know it or not, have been conducting business largely in Waterfall, or sequential, product development. It’s the way most businesses are designed to operate. Products go through stages during development, each one requiring a sign-off and approval before the next stage (which typically involves different employees) can begin.  

So, when deciding if you should switch, it can be immensely helpful to see how a new development philosophy actually works – and here is where it gets a bit interesting. Not only is there a film out there that does a tremendous job educating its audience on Agile practices and benefits…but it’s a Godzilla film. Shin Godzilla was released in 2016 to financial and critical acclaim, earning itself Japan’s equivalent of the Academy Award for Best Picture. The movie serves as a complete reboot to the 60+ year-old franchise, showing Japan facing a threat its never seen before – and really focusing on government response. The result is an almost perfect showcase of the situations where Waterfall fails and exactly how Agile can make a difference.


When and Why Waterfall Fails 

When Godzilla first appears in Tokyo Bay, nobody knows what to do. It’s a challenging scenario – and one that has the potential to shift dramatically. What exactly is in the water? What happens if it goes on land? These are the questions asked in committee after committee. Each team meeting determines and reinforces its course of action, then sends the plan along to the next department for ratification and adjustment. In short: It’s a fundamental Waterfall structure. The film’s Japanese government is numerous bureaucratic layers, each one designed to review and ratify – ensuring the best possible outcome (in theory).  

So, after numerous meetings and discussions and reviews, the government concludes that, due to the size of the creature, it’s impossible that it can threaten people on land. What happens next? Godzilla comes ashore. Not only that, but the film presents a continually evolving and mutating monster – one that is constantly gaining new abilities and growing to larger sizes. As a result, every time the traditional structure thinks they are developing a solution that might resolve the crisis, the conditions change and they are back to square one, often with tragic consequences.  

shin_godzilla

This outlines the exact scenarios where Waterfall struggles. The Japanese government is dealing with very short timetables and sending every action through numerous layers and approvals are delays they can’t afford. On top of that, they are also facing a fluid situation. Since Godzilla is constantly redefining itself, solutions that were viable one moment are soon outdated. Many organizations are facing similar challenges. They can struggle for months to create a product to meet a market demand, only to have the market shift, or have that need met by competitors who beat them to sale, or to have a client change their mind.  

Waterfall product development operates on the idea that the process of yesterday is fine for today and tomorrow, and there are many products where this makes sense. Its well-defined structure is a strength as it often highlights a viable path to market but, when conditions change, that same structure can become rigid and inflexible.  

So, how does Japan plan to save the day in Shin Godzilla? Spoiler alert: They create a new government response team with new guidelines: Be fast, be flexible, work across departments without the need of the traditional approval process. The heroes of the movie work as an Agile product development team to defeat Godzilla before it can mutate again.  

Understanding the Principles of Agile Product Development

The Agile Manifesto lists 12 guiding principles for software/product development. Many build off previous ideas to solidify the concept of fast, fluid development. Ideas like “business people and developers must work together daily throughout the project” is angled toward collaboration but still with an eye on speed. By bringing a more diverse set of operators to the table, organizations can eliminate the need for the product to move through multiple departments.  

In Shin Godzilla, this new government agency is comprised of individuals from various departments. There is even a joke that they were the “impatient trouble-makers” or the “rockstar rebels” in the traditional system, reflecting that these folks were predisposed to challenge bureaucracy and seek a more rapidly changing environment. They meet regularly face-to-face (another Agile principle) with one goal: do as much as possible as fast as possible (yet another Agile principle). They need to maximize their work by rapidly testing numerous potential options until one solution proves viable. They are only working with the direct stakeholders in government and bypassing every other level/department of the established system.  

This is Agile product development at its heart. The goal is not to satisfy an approval process but make a working product rapidly and with continuous feedback. It is an iterative philosophy that emphasizes open collaboration and transparent communication. I won’t spoil the movie but let’s just say an Agile approach produces results that Waterfall just wasn’t yielding.  

And that’s part of the real story here: We’re not saying Agile is innately better than Waterfall. It’s not. There are, however, numerous different conditions in organizations and industries where sequential product development might not be the optimal strategy. For these groups struggling to keep up against the competition, Agile might be the way to go. After all, it worked against Godzilla.  

Onshape Live: Agile Product Development

Hear from PTC CEO Jim Heppelmann and others on agile methodology and how it can be applied to hardware product development teams.

Tags:
  • Digital Transformation
  • CAD
  • PLM
  • Concurrent Manufacturing
  • Industry 4.0

About the Author

Colin McMahon

Colin McMahon is a senior market research analyst working with PTC’s Corporate Marketing team, helping to provide actionable insights, challenging perspectives, and thought leadership on trends, technologies, and markets. Colin has been working professionally as a research analyst for many years, and he enjoys examining and evaluating just how large the overall impact of digital transformation technologies will be. He has a passion for augmented reality and virtual reality initiatives and believes that understanding the connected ecosystem of people and technology is key to a company fully realizing its potential in the 21st century.