ChrisExplaining software development methods by flying to Mars
OptionalWaterfall method: talk about building a rocket for 5 years, build the rocket, rocket needs to be totally redesigned because we forgot to put a place for people to go - massive change reqeust, build new version. Project Delay: 27 years
Agile Method: a rocket is not software - do not use Agile
Kanban - kanban is agile
Scrum - scrum . . is also Agile. What are you doing, go back and do the waterfall one
Your comparison is interesting, but let’s consider some historical facts. The Apollo program, which successfully put humans on the moon, actually employed many principles we now associate with Agile methodologies.
Contrary to popular belief, it wasn’t a straightforward Waterfall process. NASA used daily stand-up meetings, self-organizing teams, and iterative development cycles - core Agile practices. In fact, Mariana Mazzucato’s book ‘Mission Economy’ provides fascinating insights into how the moon landing project incorporated elements remarkably similar to modern Agile approaches.
While it’s true that building rockets isn’t identical to software development, the underlying principles of flexibility, collaboration, and rapid iteration proved crucial to the mission’s success. The Apollo program adapted constantly to new challenges, much like Agile teams do today.
Regarding Kanban and Scrum, you’re right that they fall under the Agile umbrella. However, each offers unique tools that can be valuable in different contexts, even outside of software.
Perhaps instead of dismissing Agile outright for hardware projects, we could explore how its principles might be adapted to improve complex engineering endeavors. After all, if it helped us reach the moon, it might have more applications than we initially assume.
Also, Kanban was invented in the 40s as a process for automotive production lines. That’s why it aligns so well with maintenance and operations projects in IT. It’s ridiculous how more and more people claim it comes from software development and would not fit hardware projects, when that’s the core use case of the methodology.
Good points all - I was just responding to a comic strip that I think meant to riff on the old, “what the customer wanted”, “how sales described it”, “what engineering proposed” etc. about project management but it just wasn’t finding the funny as it put the onus on Agile like isn’t this a silly discipline - well, no. :)
Ah, here it is:
So does Agile even have a definition, or is it just an umbrella for every management method?
Agile methodology is a defined framework for software development success. It helps teams adapt and solve specific needs at a given time and prioritizes accelerated time to market and the value of user insights. Agile is based upon a set of four values and twelve principles laid out in the Manifesto for Agile Software development.
See, the thing with that is it’s just really aspirational. Anything could be Agile if you do it in the right spirit, if the manifesto is the whole thing.
Edit: I suppose what I should have asked is: “Is Agile really a system, or just a philosophy?”
It’s both. The word “Agile” is used for either depending in context.
To that end, it’s several systems depending on if it’s used for straight-software development in a department, or manufacturing with technological components, or an entire enterprise using Agile concepts like SAFe. Each one could be slightly different, and each one is some variation on the philosophy.
What it differs from is a phase-gate approach typified by project management. The big difference is project management has been around forever, Agile just over twenty years. So the former is what everybody knows by default, the latter sounding very “woo woo” to a lot of people.
Agile is indeed more of a mindset than a rigid system. In my recent experience helping a tabletop game team, we applied Agile principles to great effect. Rather than trying to perfect every aspect of the game at once, we focused on rapidly iterating the core mechanics based on player feedback. This allowed us to validate the fundamental concept quickly before investing time in peripheral elements like the looks of the game.
This approach embodies the Agile value of ‘working product over comprehensive documentation’ - or in our case, ‘playable game over polished components’. By prioritizing what matters most to players right now, we’re able to learn and adapt much more efficiently.
Agile thinking helps us stay flexible and responsive, whether we’re developing software or board games. It’s about delivering value incrementally and being ready to pivot based on real-world feedback.