• 19 Posts
  • 81 Comments
Joined 4 years ago
cake
Cake day: July 18th, 2021

help-circle



  • I agree that mental rules add complexity, mental rules such as “If I run, I’ll be seen as weird”.

    I also agree that the change to running not a reflex in the sense of “This pan is hot! I’ll instantly move my arm!”

    Without looking at the data, I’d assume the switch-to-running point is arrived at statistically. Most people have a point —or a range or a distribution of points— at which they start running. It could be that this switch-to-running point is similar to breathing: most people go from inhalation to exhalation (a point we could call switch-to-exhalation or, if reversed, switch-to-inhalation) without thinking about it, but they can also consciously control it.

    The contradiction you mentioned disappears if you don’t consider the switch-to-running point a reflex, and instead consider it like breathing. You can consciously hold your breath and therefore change the switch-to-exhalation point. You can also consciously walk faster and therefore change the switch-to-running point.

    I agree that the exhaustion is different: different muscles are being used and they’re being used differently. Maybe saying that was factually wrong. My bad. I was trying to get across the point that energy expenditure past the switch-to-running point is higher if you choose to keep walking than if you run. But the fact that there’s more energy expenditure doesn’t necessarily mean that you’ll be more exhausted; it could be that when you run, even though you can save energy, it actually uses muscles that are not properly trained and therefore get fatigued faster than the muscles you’d use if you walked.



  • Yes, I agree that it’s a hodgepodge of linked concepts. Sorry! Here’s my attempt at explaining:

    When you eat food, it’s like your battery gets filled. If, after eating a good meal you were to stand up and just stand there idly, your battery would slowly drain. Eventually, over the course of hours, you’d get hungry and need more of the food; you’d need to recharge your battery. Now, if your battery is full and you start walking, the battery will drain a little bit faster. You know this from taking walks, going on hikes, or commuting; they can make you hungrier! Now walk a little faster and the battery will drain even a little bit faster. If you take your sweet time on a walk, you will not nearly get as hungry compared to walking as quickly as you can.

    Another useful image is holding a cup full of water and tilting it more and more, spilling the water; the more you tilt it, the faster the water gets drained from the cup.

    Now, think about when you walk. When you walk faster and faster and faster, there is a point in which you automatically start running. Turns out, this point in which you go from walking to running is special because it leads to energy savings.

    Weird, isn’t it? Here’s a way to look at it: if you try to walk a long distance at a very high speed, you’ll get exhausted, but if you run the same distance at that same speed, you’ll be less tired.

    This is similar to some cars and bikes. If you’ve driven a gear-shift car or a bicycle with gears, you’ll understand that, past a certain speed, it’s much more efficient to switch gears. If you don’t switch gears, your motor will get exhausted or your legs will get exhausted. If you do, your car’s battery or your legs’ batteries will be able to push forward for longer.








  • Ah, I see how my wording was confusing. I mean planning in the sense of “How will we complete the work that we already committed to?” and “What will we do today to achieve our Sprint goal?”

    I arrived at the word planning because Scrum is sometimes described as a planning-planning-feedback-feedback cycle. You plan the Sprint, you plan daily (Daily Scrums), you get feedback on your work (Sprint Review), and you get feedback on your process (Sprint Retrospective).




  • 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.


  • 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.


  • 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.

    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.

    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.

    Regarding modern agile approaches, while no method is perfect, many organizations have found them 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 software 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.



  • 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 frequent feedback (akin to daily Scrums), self-organizing teams, stable interfaces so that teams are an independent path to production, 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. Furthermore, here’s a NASA article detailing how Agile practices are used to send a rover to the moon: https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf?attachment=true

    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 missions’ success. Programs like 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 and, decades later, send rovers to it, it might have more applications than we initially assume.