Brian Marick complains about people, like me, who prefer to use dictionary definitions of words such as agile, instead of capitalizing the word and using it as a brand name, as he does. Read his blog post here.
In his post, Brian said, It really gripes me when people argue that their particular approach is “agile” because it matches the dictionary definition of the word, that being “characterized by quickness, lightness, and ease of movement; nimble.” While I like the word “agile” as a token naming what we do, I was there when it was coined. It was not meant to be an essential definition. It was explicitly conceived of as a marketing term: to be evocative, to be less dismissable than “lightweight” (the previous common term).
Brian says he was there when it was coined. I think he’s talking about the meeting where the Agile Manifesto was produced. Actually, Jim Highsmith was promoting the term before that meeting, and spoke to me about it. Then he went to that meeting and suddenly there’s a manifesto.
Before and after the Agile Manifesto meeting, I had a number of conversations with Jim Highsmith and with Brian Marick. I served on the Cutter IT Council with Jim Highsmith, and I worked at Reliable Software Technologies with Brian Marick. We talked. It was always my understanding that “agile” meant agile. The Agile Manifesto looks to me like an enumeration of the factors that allow software development to be agile. That’s why I like the manifesto.
The idea that agile was always supposed to be a brand name and not taken literally does not hold water. This wasn’t at all what we were talking about, back then. Agile became another word for Extreme Programming about five years ago, as the inevitable forces of marketing worked their special magic.
How strange that Brian should argue that agile is a word like “glade” in Glade air freshener, as if we should have known all along that we were buying a fragrance of an idea, not the idea itself.
No Brian. You can’t have agile. Agile belongs to us, the English speaking world, and it belongs to us, the people who want to promote agility in software development. We are taking it back.
Both forms of agile need to grow and expand beyond its founding members…
Consultants stole it? No offence to anyone, I just want to say what I feel as a person who is trying to improve the process in his own medium size company for years.
There are agile as an idea. There are methodologies or set of practices intended to be Agile. There are both consultants that sell Agile and consultants who promote agile for publicity.
I’m also afraid I’m one of those who Brian is referencing to. Half a year ago I wrote that I define for myself to be an agile it only requires that “the project is capable to balance among quality and scope� through the life-cycle, nothing more.
To James:
I recognize Barry Boehm, Randall Jensen, Jerry Weinberg, Tom DeMarco, Tim Lister, and Pete DeGrace as the public founders of agile from my point of view. Those were the guys whose work I encountered in the mid-eighties. They were talking about project dynamics, which seems to me is the core issue. I was inspired and built on that.
Anyone who is seeking to lower the cost of change, rather than minimizing change itself, is working in the arena of agile processes. I think it’s that simple. Anyone can contribute. Agile is not a club.
To Ainars:
I promote agile for publicity, if by that you mean that the decriptive terms which apply to my work help me attract the kinds of clients that want what I offer. My approach to software processes and testing in particular is agile, not Agile; heuristic, not Heuristic, and centered on the skills of the practitioner, rather than Practitioner-Skill-Centered (TM).
Yes, I’m seeking to “lower the cost of change, rather than minimizing change itself”. More over I am thankful to you James Bach that you promote it, because I could refer to you and I am encouraging colleagues to read your publications, converting them into Our (let me call it so) way of thinking.
But I’m also pleased there Agile is made brand, which is recognized by upper management so it is easier for me to convince them that my agile ideas are going to work.
Maybe three small potential contributions . . .
– I usually include Tom Gilb in the crop of influences, and include non-software influences like Deming & Juran, Crosby and even Hammer and Champy. What is going “agile” but an example of designing a process less, and tossing exceptions otu to people to resolve – “Reengineering” in a nutshell, before the starched-shirt consultant hordes hijacked it.
– “Anyone who is seeking to lower the cost of change rather than minimizing change itself, is working in the arena of agile processes. I think it’s that simple.” Maybe I can modify this to: “Anyone seeking to balance the cost of change with the cost of minimizing change.” and call it “conscious development.” or maybe “conscientious development.” Both of those track to the dictionary definitions of the worlds used.
When a book comes out in the fringe of the agile scrum (puns intended) titled: “Pre Factoring”, someone has recognized that maybe, sometimes we know enough to do some things up front, and this aspect of the game has come full circle.
– This is why I don’t much like a manifesto. Better to say what you mean as clearly as you can manage, then work to connect with your colleagues and customers in those terms.
But that’s just me.
This whole “post-Agile” debate started on Jason Gorman’s blog last year, and I recall seeing some posts on the agilemodeling newsgroup about this whole Agile-with-a-capital-a thing. I think it started with him questioning the validity of “Agile Six Sigma” and questioning if “evolutionary” and “agile” (and “lean”) meant the same thing.
Original “what is agile?” post: http://parlezuml.com/blog/?postid=73
Agile vs. Evolutionary: http://parlezuml.com/blog/?postid=74
[James’ Reply: In my community, the debate about what is agile began the moment that the word was proposed, in 1999. Before the word was suggested, I was attacking the lack of agility in the CMM (see my 1994 article Immaturity of the CMM). I also wrote a 1994 paper about agile processes and process improvement called Process Evolution in a Mad World. Before me, agile concepts had been developed by a number of other thinkers. This is an old issue.
I think Kent Beck made a fine point in the white book: agile is about lowering the cost of change, as opposed to avoiding change. That’s the key distinction. The nice thing about that distinction is that it suggests where a non-agile approach can work– in situations where change can be inexpensively avoided. ]
I think the branding of Agile with a capital “A” dooms it to being replaced eventually by the next great project management practice. The reason I say this is because Agile with a capital “A” is a practice, but agile with a lower-case “a” is a principle. Eventually a new “practice” will come along that is more agile than Agile, and Agile will seem as impractical to the next generation as PMBOK does to me.
I love the principle of agility, and I am grateful for Agile’s role in promoting it. It is useful to have a practice that teaches people to appreciate the principle. The world is full of people who are not intuitively agile, and they have to be taught to value agility. A practice, like Agile, is helpful because it shows neophytes how to implement a principle. But the very fact that a practice is nothing more than an implementation of a principle means that it will someday be replaced by a better or simply different practice.
Pulled from article:
“In a way, context-driven testing may be more agile than Agile testing in that it relies on individual rationality and choice in cases where XP and even Crystal would at least begin by following rules and precedents.”
Does he imply here that heuristics are more lightweight than “rules and precedents”?
[James’ Reply: I don’t know who the author is or where he gets his information about context-driven methodology. In any case, I don’t believe that the authors of XP or Crystal follow anything but their own sense of how to solve the problem at hand. If they choose to apply rules and precedents, that is their choice. For the authors of methodologies, methodology is a game where the rules can be changed at will. It’s the people who follow those authors I worry about. The followers play the game but do not feel they can change the rules, nor do they necessarily know why those rules were made.
In context-driven methodology, all practices are treated as contingent. To be context-driven is to take responsibility for practices and re-author them so that they fit your context. In doing so, it’s certainly okay to apply ideas from elsewhere– in fact, that’s encouraged more in the context-driven circle than anywhere else. The original inspiration for context-driven thinking came out of trying to get people from different contexts to learn from each other.
Agility is a word that means easy to change. True agility in intellectual affairs occurs when the practicing intellectuals get to change their problem-solving behavior to fit the problems that they actually face. Anything inconsistent with this isn’t agile, however much Brian Marick may desire the marketing value of that word.]
Probably not. I had thought of XP as a bunch of hueristics the formed [in phlips words] “a strange attractor for producing good software”. XP/Crystal would still depend on individual rationality to apply them, so he perhaps mislabels them as depending on rules and precedents.
BTW, having your first rule be to “rely on individual rationality” may be self-contradictory, there are some cases where you might not want to do that 🙂
What is the first heuristic to apply in context-driven in any situation?
[James Repy: There can be no best first heuristic, but one thing I often do is ask myself “Who am I and what am I doing here?”]
Thanks for rely James…:-)
If you answered your question generally enough it would be the same every time, suppose you were here to solve some problem…
Could a reasonable first heuristic be:
1) contact the problem
?
2) ask “what works?” or “what still works?” or “how does it work?” of “how does it not work?” That is, break it down.
I don’t know the third step. These two are a macro-process, or diving board for this other pool of heuristics:
http://www.triz-journal.com/archives/2005/01/04.pdf
http://www.triz-journal.com/archives/2005/05/04.pdf
Seems like there is profit to be made by doing Step 1) as soon as possible, because it’s never done til the end usually. Developers are kept away from the problems. Only in the end the problem goes away when developers finally end up contacting the problem by asking questions about it.
Revised step 1)
Instead of defining requirements, put problem solvers in contact with the actual problem as soon as possible. What could be agiler?
Cheers,
-Rich
[James’ Reply: Sure, you can contact the problem, first. Or you can do a lot other things, such as centering yourself, first. In context-driven methodology, we eschew universal solutions, so the more interesting question to me is “what kinds of things might we try first, and why might they be interesting to try?”]
Choice then. I like it. No need for only one compulsive thing to do at the beginning. Choosing to move in one way or in a different way works well for tennis too…going from known to unknown. It’s funny you don’t do as well when you know what you’re doing.
Best,
-Rich
It occurs to me that every company could have it’s own “Agile”, meaning it’s own set of best practices accompanied by some kind of name beginning with an uppercase letter, or better yet, a TLA (Three-letter acronym). Perhaps that could be a profession all its own. That is what I’m attempting to do in my role as SDLC manager at a small company.
[James’ Reply: You could do that, and then NOT call it a set of best practices.]