Beautiful!<p>The thing that really kills me about this is that 90% of the people who are "doing Agile" (which is not a thing that you can do [1]) really believe that they are an Agile shop. And then I will ask as many as 3 questions to find out what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old days I could say, "Hey, you should try one of the Agile processes." Now they think they are doing that and doing it well (after all, they have certificates!), so what can I even tell them?<p>Everybody I talk to who was involved in the Agile movement in the 2000-2004 time frame has this experience now. Common reactions are rage, tears, and philosophical resignation. (I favor quiet rage, but I suspect resignation would be healthier.) That there are some shops doing very well is consolation, but the early Agile people were hoping for more.<p>For the whippersnappers who are curious about now-ancient history, my theory on how we went wrong is here: <a href="http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/" rel="nofollow">http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...</a> A big lesson I learned was that if you don't have a trademark and use it to keep quality high, your popular term will get buzzworded to death.<p>[1] Agile is an umbrella for actual processes, like Extreme Programming. There is no process called Agile to do. Saying you are "doing Agile" is like somebody saying their house is in America, but not in DC or any of the states, just America. If you point out that it's the <i>United States</i> of America and they have to be somewhere; they just shrug.
In my language we have an ancient term/story called 'Yaanai Kanda Vaadham' meaning the 'debate on the elephant' (the origin of the story is controversial so lets leave that out). Perhaps you have heard the story, four blind friends come across an elephant, each one holds a part of the elephant and equates it to what he knows and understands. Hey! there is a wikipedia page on it<p><a href="http://en.wikipedia.org/wiki/Blind_men_and_an_elephant" rel="nofollow">http://en.wikipedia.org/wiki/Blind_men_and_an_elephant</a><p>When merits of processes are discussed devoid of its purpose (delivering quality software in business relevant time), the argument is similar to the story. The process is just the means of reaching the purpose isn't it? It is not like successful software was delivered only in the last decade, we have been to the Moon and back before that.<p>Unfortunately, processes are always made in good intention to achieve a purpose, this when transmitted from one person to another becomes a system, as there is no guarantee or way of enforcing 100% knowledge for all people in the chain. This deviates it pretty quickly from the purpose with focus only on the practice and soon the system becomes a religion.<p>Then surprise! people shed blood over it after that demanding that their book is the only truth :-)
In my experience "agile" isn't really a thing, more an excuse or reason to not follow any rules at all. Devs get to play at building whatever they like, solving the problems that interest them in a haphazard way and leaving behind a trail of half-written, semi-functional code with little or no documentation to allow anyone to work with them. As soon as anyone suggests that there's a plan, or god-forbid, an objective or expected outcome from the invested money, everyone suddenly scream, "AGILE" and that, apparently, is enough to shutdown any and all detractors.<p>But then, try to suggest that there's a requirement that has changed or come to light and suddenly the "agile is open to new requirements" part of the approach is forgotten as the "progress" that's been made so far is too precious to change.<p>/rant
It is a plain fact that people rarely distinguish between philosophy, religion, and culture. As a former mormon who served a mission in a foreign country, I witnessed this first hand: American missionaries (mostly from Utah) trying to superimpose their culture on foreigners and calling it religion, while foreign members pushed back (appropriately IMO) when they felt that the religion didn't really clash with their culture which was being stripped from them.<p>Now I am seeing this from an outside perspective; I'm not a programmer or software engineer but I work directly with them in a weird sort of non-supervisory product manager role. In my opinion, this is no different...in fact, "Agile", which as far as I can tell is nothing more than a hand-wavy underspecified form of Extreme Programming, has so much ambiguity in its definition that you can't ask any two advocates and get the same response as to what it is. And as such, whenever there is a problem with the outcomes of the process, the only apt response is the No-True-Scotsman fallacy...which makes development descend into the phenomenal failure of productivity that all holy wars are.<p>This isn't unique to Agile. Lean and Six Sigma are also mixed bags of philosophy and process, and they have been mixed bags of occasional success and phenomenal failure.
This post gave me flashbacks.<p>I once had to sit through an 8 hour pre-kickoff meeting detailing in excruciating detail how our team was going to be "agile". It involved at least 400 slides, described a weeks long change request process, and two-month long "sprints". Even as a junior dev I know I am lucky I never had to suffer through the rest of that contract.
One word: budgets. The problem with "enterprise" isn't their reluctance to adapt agile principles, but rather that people need to know "if I pay X, then I should get Y" - agile basically says "we think we know what X is, and we know your version of Y isn't what Y will become"
As someone working in enterprise, this manifesto sounds almost exactly like how we use Agile here. The term "Agile philosophy" (instead of methodology) was coined to go with our loose interpretation of what Agile should be.
I dunno, sometimes going back to waterfall sounds kind of nice. I'm tired of the lack of direction, the attention-deficit school of project management where every 3 months there is some new starry-eyed vision we all chase after. I know this means my company is "doing agile wrong" and all that shit, I just would rather be on a slow train wreck than a fast one.
It's interesting because "agile" can fail on both sides. This lampoons the enterprise side, in which you adopt "agile" practices inside rigorous change control and long requirements documents. But there is also the cowboy/ninja failure mode, in which "agile" is used to rule out any strategic thinking, technical design, or requirements gathering.<p>Not only can you fail on both sides, but you can be too far on one side and think that you haven't gone far enough.<p>I've had startups tell me they were doing Scrum, but it had gotten so hard to estimate their work that they had "broken agile" by having "grooming sessions" to talk to stakeholders about upcoming work before it got into sprint. They were shocked to learn this was a required part of Scrum and that many books recommended that being up to 10% of the team's time.<p>Another company I talked with was so concerned about their developers "continuously delivering" code that they were fighting to be "more Scrum" by changing their QA folks to be in a staggered sprint one week after the developers. They were shocked to learn that this was a widely-tried and widely-panned approach that was philosophically opposed to the roots of Scrum.<p>Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works, and can quickly spot people who don't understand the philosophy. Has anyone else experienced this? I wonder whether it is real experience or just an illusion my brain has created to give meaning to many months of painful trial and error.<p>Nowadays I think of scrum as being about holistic product creation, about building a team that can deliver what customers will pay you for over the long-term. That requires breaking down most "process" to get "one-piece flow" on a complete team working as one to deliver new features. But it also includes the team building its own processes to make sure they are building the right thing to a high level of quality.<p>That vision is anathema to cultures that value technical prowess, or pure speed, or meeting corporate objectives, or anything else other than building a team that can deliver value to customers over the long term. It's a challenge and a priority change for both corporate political environments and built-to-flip startups. And it's surprisingly hard to find a company that wants to pay you to build things their customers like, rather than using some other metric.
In the best of worlds your practices evolve from your principles. Compound the relationship between your principles and _current_ practices with the effects of the real world and you end up somewhere in between. That's life. It's easy to stand from a "higher elevation" like a consultant might, point your finger and say "You are not doing this." It's a harder thing to really make it happen.<p>I see parallels in people bickering about whether some element of a service is or is-not RESTful, when maybe 95% of the functionality of the service is acting/quacking like a duck.
This is so on point for any company not just software ones. I work at an NGO and not a tech company, and this just reminds me of every meeting we have about internal processes.<p>We end up creating grandiose plans, but they usually just turn into endless bullet points for strategic road maps rather then actionable items
This reminds me that anything "Agile" and enterprise business is fundamentally incompatible thanks to the quarterly earnings report (for public companies at least).
I've been a little disappointed to find out that aspects of this view are sometimes adopted at startups with a lot of VC funding, and not just enterprise companies.