ChrisExplaining software development methods by flying to Mars
antonWhat is the methodology called where you:
Plan to go to orbit, blow up seconds into the flight, and declare it a success.
Plan to refuel in orbit, make it minutes before the rocket brakes. Fire the FTS, it fails, the rocket blows up a minute later und declare it a successful test of the FTS.
Argue to NASA that you are not the limiting factor to the moon mission planed for the end of the year, despite delivering none of the milestones.
FTS = flight termination system
HominineAn improvement.
Sounds a bit like the S&M methodology. SpaceX & Musk
Tbh it actually sounds a lot more like Boeing these days. F9/F9H is bulletproof reliable these days, and starship is making HUGE developmental strides, while Boeing is still failing to discover and iron out system integration bugs and hardware faults years after they had “completed the project”.
mrbnIt’s a feature, not a bug
Getting to space. Fuck Musk, but SpaceX is doing great work.
ZarlinThat’s called R&D, Research and Development. As long as you learn from a failure, it is progress towards success,
This is the Kerbal methodology.
I take it you missed the recent fourth integrated flight test, in which the ship soft landed on the ocean near Australia as planned and the booster soft landed on the ocean near the launch site as planned
Their failure in that flight was expected. They hoped thermal tiles sealing the hinge for the aerodynamic surfaces would seal those against plasma during reentry. They didn’t. Had they, it would have been much cheaper than sealing those more thoroughly. The ship landed regardless of that failure
ArtemesiaSo 3 minutes+ (first test) is "seconds", and rapid iterative development with early integration is not a programming methodology? You know that most mastodon servers prohibit counterfactualing, right?
For the record, 2nd test flight put the payload into the assigned orbit.
4th test flight got as far attempting a simulated landing (on water). Meanwhile, every other launch vehicle meets a hot flaming death in the atmosphere after delivering their payload to orbit (like test flight 2 did), because they don't even try to land their vehicles after boosting.
Your problem is what, exactly, besides yourself? The hurr-durr is strong with this one.
I call that following the same successful recipe that got us the Falcon 9
I think this is a bit disingenuous. There’s no customer interaction in these panels.
So waterfall would be: Customer says they want to go to Mars. You spend years building a rocket capable of going to Mars, draining all the company budget in the process. Customer then clarifies they actually meant they wanted to go to Mars, Pennsylvania, USA - not the planet!
Carighan MaconarAlso the strip stops midway through as Waterfall was an invented thing just for a paper. And during your UP work you actually had the customer put in that input and hence it was like in this cartoon strip.
This is depressingly accurate. 😓
Like yes, but undone armpits generate more wealth than the rocket to Mars
Heh… Armpits. I know what you meant, but you still gave me a giggle with that one.
Sorry, was writing it from the toilet. Needed to hurry in order to not miss a PBR
Firecracker looks proud. Really brightens my night.
Waterfall 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.
Agile / scrum sections do not contain hours of useless ceremonies.
The art style is nice but the content makes no sense. Kanban and scrum are parts of agile. They are not their own systems.
Lean also doesn’t mean you have no money. It’s a system of manufacturing where you cross train people to do the jobs on either side of them so they can pick up slack if needed and keep things moving without hiring more people.
woodenskewerLean is also short for putting your inventory in an open top dumpster.
bloubzThis can be funny but nothing is right. Kanban is not a method and can be found in agile methodology and lean, scrum is also an agile methodology, and they are wrongly defined
Quick google shows that it is a method. Main around picking up things as the come, but also limiting how much can happen at once.
The project I’m has a team that uses Kanban for the “Maintenance” tasks/development, take what is at the top of the board and do it. Adapt if higher priority things comes around, such as prod bugs. Our developments teams are trying to implement Scrum, where interruptions are to be avoided if possible during sprints. You plan a sprint, try to do that work, and can present it, and iterate when users inevitably changes criteria.
Kannan is just a board. You can implement different things with it, like pull system, one piece flow, prioritizing, etc…
Someone shared this on Mastodon so I’ll just repost my thoughts from there. (Bonus for Lemmy, I was forced to squeeze all my thoughts into 500 characters, so this is the most succinct I’ve been on this site!)
Pretty incredible how little people seem to understand these. For one thing, every method other than waterfall is a subtype of agile methodology. The major distinction is that waterfall has a series of phases from design through building, testing, and delivery that attempts to plan the whole project up front. Agile methods focus on smaller iteration cycles with frequent, partial deliverables.
Something like kanban is designed for continuous delivery: we want to go to mars weekly.
LEAN development is a scam though, that one is accurate.
The author is also hyping up waterfall too much. Agile was created because waterfall has its shortcomings (the team realizes too late that what they’re building isn’t what the customer wants).
But I also think it also represents how poorly implemented these ideas are. People say they do agile/kanban/scrum, but in reality they do some freak version of these.
So often it’s waterfall planning and execution with agile names for roles and meetings.
It’s barely waterfall planning either. Often there’s no planning, at least no coordinated one.
Currently at my current workplace we lack coordinated planning between teams. It seems like everybody is working in their own directions and it can take months until we get feedback from other teams. Mostly a product management problem.
I agree, but agile and scrum are not meant to be followed to the letter no matter what. So people are doing it right if they notice some part of the process should be changed to make it work for them.
Except they often only appear to work.
The amount of people who say they do agile/kanban/scrum but have never talked to a customer/end user, let alone released something, is frightening
ulternoLEAN from the web:
After each iteration, project managers discuss bottlenecks, identify waste and develop a plan to eliminate it.
1st iteration:
Project Manager A: Requiring approval of multiple Project Managers for the same thing is causing a bottleneck. So is having to wait for a specific manager for a specific topic.
Resolution: Let all managers approve everything and need only a single manager’s approval.
2nd iteration:
Project Manager B: There are too many redundant managers. It’s a waste of resources.
Resolution: Get rid of all mangers but one. Actually, let the engineers manage themselves.
3rd iteration:
Consensus: LEAN development is a scam though
My impression of management science, at this point, is that it’s not. The good ones just do it.
RonSijmCowboy Programming:
PO: Hey we want to go to Mars
- 3 weeks of silence -
Developer: Hey I’m there, where are you?
This is the way.
Assuming you know the developer isn’t a shitbird, because you’re the developer. If this was Investor Humor the idea would be less popular.
PO: Someone else figure out how to repeat what he did.
Second developer: Sorry, I tried to make sense of his rocket design but I can’t figure out how to make a copy that doesn’t explode before we even put the fuel in.
Edgy meme: Claims agile doesn’t work
NASA: “Yep, we are agile” ntrs.nasa.gov/api/citations/…/20160006387.pdf?att…
NASA also built the space shuttle, which was a plane that couldn’t fly by itself (as it was supposed to), was slower to turn around and more expensive than older equivalent technologies, and blew up all the astronauts 1.5% of the time.
I mean, they’re great at other things - who else could have made the JWST work flawlessly with one opportunity - but they’re a definite source of hype, and they do something very particular and specialised. Beware endorsements.
Edit: Fuck you, I’m right. Keep 'em coming.
I don’t even care about Agile either way. This just isn’t a good argument for it.
NASA also successfully flew a helicopter on Mars first try.
Yep. They’re probably better than anyone at making a complex system with literal moving parts that works 100% of the time, the first time. On a nearly unlimited budget, with a decades-long schedule. In an institution and culture that’s now a been around a lifetime, staffed with top-notch people.
That’s all perfect for what NASA does, but I wouldn’t recommend a management system that NASA uses to just anyone, just 'cause “da astronauts” use it. Not any more than I’d recommend drinking your own distilled piss to anyone.
I don’t really have an opinion on Agile, even, I just have a problem with selling it this way.
That’s fair enough. The common misconception is that waterfall is great for space missions, when NASA is doing agile.
I agree that not everybody is NASA, so what works for them doesn’t necessarily work for everyone.
I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I have also been on the receiving end at times… I appreciate you sharing your perspective, even if it goes against the majority opinion here.
Your points about the space shuttle program’s challenges are valid and worth discussing. It’s important to note the timeframes involved though. The shuttle was developed in the 1970s, well before agile methodologies emerged in the 1990s and 2000s. So those approaches weren’t available during its initial design.
Regarding agile, while no method is perfect, many organizations have found it helpful for improving flexibility and delivering value incrementally. NASA’s recent use of agile for certain projects shows they’re open to evolving their methods.
I’m curious to hear more about your thoughts on development approaches for complex engineering projects. What do you see as the pros and cons of different methodologies? Your insights could add a lot to this discussion.
I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I appreciate you sharing your perspective, even if it goes against the majority opinion here.
Thanks for the kind words. FWIW I’m doing fine, this feels like a worthy fight. I know a bad appeal to authority when I see one.
Interestingly, one could argue that NASA may have used agile-like practices in the space shuttle program, even if they weren’t labeled as such at the time. However, I did a quick search and couldn’t find much concrete evidence to support this idea. It’s an intriguing area that might merit further research.
There’s somebody else in the thread talking about the Apollo missions and Agile. Uhh, here, because I don’t know if federated comment links are supported yet. There’s no source for that already provided, though.
What do you see as the pros and cons of different methodologies? Your insights could add a lot to this discussion.
Honestly no. Sorry to undercut you a bit, but I’m not going to be the Dunning-Kruger guy. I know that I don’t know project management.
I appreciate your candor about not wanting to speak on topics outside your expertise. That’s commendable. I wonder if we can still talk with the understanding that we may not know it all. I truly believe curiosity is able to sidestep many of the problems related with ignorance.
You’re right to be cautious about appeals to authority. My intention wasn’t to suggest NASA’s use of Agile validates it universally, but rather to counter the OP comic’s implication that Agile is inherently incapable of achieving significant goals like space exploration.
Regarding Agile-like practices in earlier NASA projects, you’re correct that concrete evidence is limited. However, we can analyze their approaches through the lens of Agile principles. Scrum, for instance, aims to foster characteristics found in high-performing teams: clear goals, information saturation, rapid feedback loops, adaptability to changing requirements, and effective collaboration. These elements aren’t exclusive to Scrum or even to modern Agile methodologies. The key is recognizing that effective project management often naturally gravitates towards these principles, whether formally adopting Agile or not.
It’s an interesting area for further research: have complex engineering projects historically incorporated elements we now associate with Agile? If so, how?
Your skepticism is valuable in pushing for a more nuanced understanding of project management across different domains.
Match!!Going to the moon as a step towards going to Mars is so eminently correct that this comic should actually be Agile propaganda
It’s like camping in the garden, in the hopes you’ll reduce your commute.
This is waterfall method propaganda! It never works out this smoothly. They probably forgot important requirements like: the astronauts need to be alive on Mars.
This is what I came to the comment section for.
If like me you’re not a pro, it seems to literally just mean linear phases, so yeah, any nonlinearity would cause problems.
Waterfall is missing the part where the customer realizes they didn’t actually want to go to Mars they just wanted to view it out of a telescope.
But now they can only travel to Mars and the telescope is out of the budget because you spent so much money on the rocket
Bezier2 years in, the rocket is soon to be handed over. A loud “oh fuck” echoes through the hallways. It’s now up to the lawyers to figure out who’s at fault.