Every few years, I feel compelled to write about the early days of the Agile movement, at least as I remember them. My memory is not perfect, and my lens is absolutely narrower focused, but I still find it useful, maybe others might as well. My experience with the early days was via the newsgroups where much of this was argued out, and through the early XP Universe conferences.
Lets start with the big myth. Agile was not created to find jobs for consultants or to create a certification mill. The people who invented the approaches that later became Agile were already highly respected either as consultants or just really good developers. What happened was they, as were so many of us at that time, were unhappy with how software was being developed. They came up with a better way, felt it was a better way, and shared it.
Here's what I recall happening. There were a lot of arguments on the newsgroups, especially the Yahoo e-group dedicated ostensibly to XP. Many of them were especially useful. I recall Kent Beck asking for feedback on what might be missing in the XP values, and many discussions leading to the inclusion of "Respect" as a value. Some of the discussions became much more heated, and for some reason the most heated were around whose process(Scrum, XP, DSDM, Crystal, etc...) was best. Then...all of a sudden...the major players(Uncle Bob, Kent Beck, Ron Jeffries, Alistair Cockburn, et. al.) disappeared from the newsgroup. It got really quiet, for about a week. At the end of which, we saw a posting about "If you were wondering where we've been, we went to Utah, and came back with this thing we are now calling Agile". My interpretation was that they had gone to finally end the arguments about processes, so we can focus on making better software.
So what did we end up with? A brief statement of values and some principles that the originators felt support those values. Whenever I hear someone say "Agile doesn't allow x" or "Agile says you have to do Y" I get a little twitchy. Agile doesn't say you have to or can't do anything. It is merely a guide to some thoughts that will help you in how you approach creating software.
The reason we end up with these misunderstandings has more to do with a willingness to conflate Agile with a specific procedural framework, usually Scrum. A faithful implementation of Scrum can fit nicely under the Agile umbrella. If you find the implementation is becoming too much about the process, then go back not just to the Scrum Guide to make sure you are "doing it right" but also to the manifesto. Is the way you are approaching Scrum, or any other process, still fitting in with the values expressed? If not, then no matter how closely you follow the rules, you are not being agile.
Finally, ask yourself if what you are doing is working? If it isn't consider changes based on what we have learned under the Agile umbrella over the last 20+ years. If it is working, why do you care if it fits in any particular category? Just keep making great software!
תגובות