| | "Agile is NOT a methodology". in the Ask HN that started this, he did put methodology in literalized fingerquotes, so he didn't actually make the egregious error you decry. | 5) Agile "methodology" when used as anything but a tool and his summary point still applies right on target because the Agile "manifesto" does not solve what he identifies as the problem: I think overall we seem to be over-complicating software development. We look to architecture and process for flexibility when in reality its acting as a crutch for lack of communication and proper analysis of how we should be architecting the actual software. dear Agile Manifesto, The best architectures, requirements, and designs
emerge from self-organizing teams? so therefore self-organizing teams always produce the best architectures... anybody see an error in reasoning? Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely. Suuure they do, and that's why we see Agile processes adopted by winning NFL teams, or in the ERs at hospitals, and... Look, there is a Zen Buddhist ideal for living your life in harmony, but it's a goal, not an emergent property of self organized teams. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. So, do not look up information in a man page, instead ask me and I will read it to you... that metric-imperial problem that lost that space probe, why another scrum or two would have identified that right away! I could keep going, but this letter is too long already. Yes, software does offer some advantages over other types of team problem solving (due to the possibility of virtualizing or dummying any of the parts) but because of that flexibility it becomes even more important to nail down as much key design infrastructure as possible, and the Agile Manifesto does not read like a manual for nailing anything down. (And software alone offers the possibility to rip up things that are nailed down, so we don't need to fear nailing down.) Love, philosopheer |
My attitude when looking strictly at agile doctrine is a mix of skepticism (especially after having learned and practiced agile for around 15 years now) and thinking, "Hummm...they might be onto something..." I don't often criticize the written word of how people try to describe agile, but instead try to understand "what were they trying to say?"
A point of illumination for me as to which parts of agile I was most interested in developing a deeper practical knowledge of, happened after I watched a few documentaries on Skunkworks, and how that group operated. Robert Kelly's 14 Rules and Practices does (to me) have a lot of conceptual similarities with the manifesto, especially when you see how they were practiced on some of the most difficult technical challenges humans have ever faced:
http://lockheedmartin.com/us/aeronautics/skunkworks/14rules....
I think that if someone were to pin me down and say "Tell me the doctrine you follow!!!!" and I was forced at gunpoint to give a simple single answer I would point to Kelly's 14 Rules over the manifesto.
A deeply unfortunate fact of the agile's history is that the C3 system wasn't really very successful by just about any dimension:
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
I've been told by many of Agile Manifesto acolytes that the C3 project's less-than-stellar results don't matter, but I personally think it does. At a minimum, at least you can point to Kelly's Skunkworks team, and see how they shaped modern history with their inventions and ability to deliver improbable solutions on an impossible schedule.
In summary, where Kelly's 14 and the Agile Manifesto & Principles conceptually overlap, I believe there is much worth learning.