Brian Marick has offered a definition of agile methodology. I think his definition is strangely bulky and narrow. That’s because it’s not really a definition, but an example.
Those of us who’ve worked with Brian know that he doesn’t like to talk about definitions. He’d rather deal with rich examples and descriptions than labels. He worries that labels such as “Agile” and “Version Control” can easily become empty talismans that can turn a conversation about practice into a ritualized exchange of passwords. “Oh, he said Agile, that must mean he’s one of us.” I admire how Brian tries to focus on practice rather than labelling.
Where Brian and I part ways is that I don’t think we have a choice about labels and their definitions. When we decline to discuss definitions we are not avoiding politics, we are simply driving the politics underground, where it remains insidious and unregulated. To discuss definitions is to discuss the terms by which your community governs itself, so that we do not inadvertantly undercut each other.
Here’s an example of how postponing a conversation about definitions can bite you. A few years ago, at the Agile Fusion peer conference I hosted at my lab in Virginia, Brian and I got into a heated debate about the meaning of the word “agile”. He said he was completely uninterested in the dictionary definition. He was interested only in how he felt the word was used by a certain group of people– which group, it turned out, did not include me, Cem Kaner, or very many of my colleagues who can legitimately claim to have been working with agile methodologies since the mid-eighties (or in one case, mid-sixties). Perhaps because of Brian’s reluctance to discuss definitions, our disagreement came up out of the blue. I don’t know if it surprised Brian, but it shocked me to discover that he and I were operating by profoundly different assumptions about agile methodology.
Actually, I have had many clashes with people who claim to own the word agile. It’s not just Brian. But some agilists in the capital “A” camp don’t limit themselves to it. Ward Cunningham is a great example. Find Ward. Meet him. Talk to him. He gives agile methodology a good name. I have had similar positive experiences with Alastair Cockburn and Martin Fowler.
There are at least two agile software development communities, then. My community practices agile development in an open-ended way. We support the Agile Manifesto (in fact, I was invited to the meeting where the manifesto was created, but could not attend). However:
- We do not divide the world into programmers and customers.
- We do not demand that everyone on the project be a generalist, and then define generalist to be just another word for someone who remains ignorant of all skills other than programming skills.
- We believe there can be different roles on the team, including, for instance, the role of tester; and that people performing a role ought to develop skill in that art.
- We don’t limit our practices to fit guru-approved slogans such as “YAGNI” and “100% automated testing”, but instead use our skills to match our practices to our context.
- We don’t accuse people who question practices of “going meta” as if that is a sin instead of ordinary responsible behavior.
- We aren’t a personality cult. (if you ever hear someone justify a practice by saying “because James Bach said so” please email me so I can put a stop to it. I like being respected; I hate being a blunt object for ending a debate.)
- We don’t talk as if software engineering was invented in 1998.
- We question. We criticize. We learn. We change. We are agile.
- When we make definitions, we strive to be inclusive and try not to redefine ordinary English words such as “pattern” or “agile”. Specifically, we probably won’t say you just don’t “get it” if you cite the dictionary instead of using approved gurucabulary. GURUCABULARY: (noun) idiosyncratic vocabulary, often a redefinition of preexisting words, asserted by one thinker or thinkers as a way of establishing a proprietary claim on a field of interest.
I want to offer an alternative definition for use outside of the insular world of capital “A” agilists.
First, here is the Websters definition of agile:
agile
Function:adjective
Etymology:Middle French, from Latin agilis, from agere to drive, act, more at AGENT
Date:1581
1 : marked by ready ability to move with quick easy grace *an agile dancer*
2 : having a quick resourceful and adaptable character *an agile mind*
Here, then is my definition of agile methodology:
agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.
A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.
Brian Marick’s definition of agile methodology is an example of how one community approaches what I would call agile methodology. My definition is intended to be less imperialistic and more pluralistic. I want to encourage more of us to explore the implications of agility, without having to accept the capital “A” belief system whole.
Fight the power!
Very interesting post! I don’t think all things about Agile with a captial ‘A’ are necessarily bad though 🙂 In fact I have found many advantages of adopting an agile approach.
For further information about my experiences of “Agile”, please take a look at my blog:
http://www.allaboutagile.com
There’s also an article about 10 key principles of agile development, especially handy for those new to agile:
http://kw-agiledevelopment.blogspot.com/2007/02/10-things-you-need-to-know-about-agile.html
Kelly Waters
http:/www.allaboutagile.com
[James’ Reply: I haven’t seen much benefit in the capital “A” agile. I like the small “a” version– agility that means agility; agility that is no mere brand name or personality cult. I believe that Agile projects benefit when they are also agile projects.]
Wow, how much useless bullshit you’ve written about Agile Methodologies. You have no point, your arguments are empty, and your definitions are stupidly wrong.
[James’ Reply: Hi “John”. I realize that you are hurt and scared. It is definitely scary, sometimes, to come out in the open and subject your ideas to challenge and refutation. Maybe you’re worried that I will humiliate you in public if you try to tell me the reasons and evidence that support your point of view. It’s okay, I understand. One way to protect yourself from that is to think through your concerns and present them one by one. Try to make clear the underlying logic of your position.
Perhaps you can pick an argument of mine that you find empty and explain why you believe that. Perhaps that will give me an opportunity to improve it.]
James,
Amazing response to John. Wish more people thought and acted like yourself. Then, this would be a much better and interesting world to live. Think of how many people could learn about themselves, others, and new ideas just by coming out in the open and challenge another – with respect of course.
Rob
Hi, James — Being one of the people there when we came up with the word ‘agile’ (sorry you couldn’t make it!), it is interesting to go back and reflect on what we were talking about then, and how the word ‘agile’ has come to take over what we were talking about at the time. I think you will appreciate the difference …
We were trying to say something like, “We get the sense that we’re operating differently than a lot of people out there – but suspect also that there are others out there operating in the same sort of fashion we are, and here’s how we best-at-the-moment capture what that way of operating is …”
We were then discussing several aspects of software development – only one was which was “lowering the cost of change”. It happened that “our way of operating” would, among other things, lower the cost of change, but lowering the cost of change was only one aspect.
A second aspect that ran through the discussions and shows up regularly in the agile literature has something to do with shifting the social structure in/on/around development teams. IIRC, Kent Beck and Ken Schwaber were perhaps loudest about it, but it seems all of us had something about this in our heads. Ken’s ScrumMaster course is, in fact, all about shifting the social structure in/on/around the development team.
Even stripping out “social reform” from any intentions (which may or may not have been on people’s mind), this second aspect has something to do with aligning the development teams’ work with the direction of the business, and that is very important (and often cited about agile development). Among other things, it calls for close business collaboration, which is possibly more about business alignment than about reducing cost of change.
So perhaps instead of “agile” development, we could have called it “business aligned” development. Not as catchy, of course, but then you might have been inclined to cast your definition of agile methodology as
“Business Aligned Methodology”: a system of methods designed to maximize the alignment of the work done by the developers with the direction needed by the business at the time, especially in a context where the business direction changes frequently.
and “Non-business-aligned methodology” defined with the similar inverses as you have.
Sorry about this long reply to your posting, but I think this has been bubbling up inside me for a while, and your clear definition of “agile methodology” based in the dictionary definition for one word used to capture (at least) two concerns, is what triggered it.
Is there a correction for your definition? I’m hesitant, because it took a lot of thinking and even a lot of words to describe it in the agile manifesto, so I always say, “Go back and look at the agile manifesto.” That has 4 values, not just one. However, taking my life in my hands, here goes with a tentative version based on the above line of reasoning:
“agile methodology”: a system of methods designed to allow the development team to match and track the business needs, especially in a context where business needs change frequently, important facts change, or where we are obliged to adapt to important uncontrolled factors.
I also am allergic to “non-agile” methodology, because agile is an adjective, a selection of priorities, and doesn’t have a decent “opposite” — there is another center around a different selection of priorities. That having been said, try this:
“Non-agile methodology:” … one that optimizes toward a different priority, for example, seeking to achieve cost efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.
Apologies for the long reply – hope it does some good.
Alistair
[James’ Reply: Hi Alistair. I appreciate very much that you responded. My short response it that your changes to my suggested definition look good to me. I could accept them.
However, I don’t quite understand your interest in emphasizing business needs, because that suggests someone somewhere is purposely doing software projects in a way that does not align to business needs. I don’t think the people I’ve argued with, even the ones I respect the least, would claim to be flouting business needs on purpose. I accept your change, because it does no violence to anything that matters to me, but I worry that I may not understand the problem you are trying to solve.
I liked the Agile Manifesto, which is nicely open-ended. A problem I’ve had with some Agile advocates is when they also have a set of specific practices that Shall Not Be Questioned; when doing things in a different way would offend some agile demigod looking down from Olympus. An example is TDD. To deny the importance of TDD, in some parts of the Agile community, is treated as immoral. It seems to me a very un-agile attitude. People like you and I rethink things for ourselves. How can we deny others that same privilege? Of course we wouldn’t– with one exception: if someone is working for me, and I am responsible for the quality of his work, then I can dictate how I want that work done.]Â
with respect to: {{I don’t quite understand your interest in emphasizing business needs, because that suggests someone somewhere is purposely doing software projects in a way that does not align to business needs. }}
I don’t think so … any more than w.r.t. your definition of agile {{agile methodology: a system of methods designed to minimize the cost of change, }}. Using your logic back at you, you would say that that definition of agile is no good because it implies that there are people who are purposely trying to not minimize the cost of change.
[James’ Reply: The difference is that I’ve already run that test on my idea. 🙂 There are many people who are purposely not trying not to minimize the cost of change! Are you kidding? The traditional linear methodologies promoted by process people who didn’t really understand cognitively intensive work were definitely trying, on purpose, to avoid change, rather than to structure things to naturalize change. Note that there is a big difference between purposely trying to maximize the cost of change and purposely not trying to minimize it. Having said that, I actually do think some process people (consultants and outsource vendors especially) do try to maximize the cost of change as a way of penalizing their customers for disrupting their plans, or as a way of maximizing the money they make in billable hours. Agile is a family of strategies for doing good work, and so is non-agile. The difference between agile and non-agile is not that one is good and the other is evil, or one is smart and the other is dumb. I just happen to think that non-agile approaches don’t work well in a chaotic world, and the idea that we can stamp out chaos is obviously one that hasn’t worked. Non-agile methodologies can’t compete well in a world where we want good technology for a reasonable price.]
All I intended with the redefinition was to highlight that “minimiziing the cost of change” is only one of the aspects, features or perhaps even side-effects of “the way we are choosing to work.”
[James’ Reply: It may be that you are also trying to promoting a humane way of working.]Â
John Rusk (in New Zealand) already responded to my post with a correction to my words that I think is quite fit. i include it here:
{{I’d actually expected you to think something slightly different to what you wrote below. (Perhaps an erroneous presumption on my part! 🙂 I always remember your comment about coming to agile through the door marked efficiency, rather than the door marked changing requirements. I had presumed that “agileâ€? (in the manifesto sense) was intended to capture the essence of a bunch of similar methodologies, some of which were very conscious of reducing the cost of change (XP), some of which were conscious of reducing the initial cost of development (Crystal’s efficiency), some of which were focused on the social structures of teams. The essence was none of the above. It was about successfully producing software, and a better understanding of how that should be done. All the processes had learned to value people in a different way to traditional processes (your safety, habitability and people as first order…). }}
I like the fact that John highlights that we all came to the meeting _with our own value sets_ and found an area of commonality across them. Which means that finding the “true center” of agile can’t be done. Kind of like in the “old towns” in Europe … the “old town” is the center of the city, but the “old town” has no center itself – it’s just a little maze of twisty passages, all different. I thank John for reminding me of this.
Alistair
[James’ Reply: It seems that you have named your issue– one word can’t sum up what you are trying to say. But here’s my issue– I think there is value in pursuing methodology that could reasonably be described with that one word. That’s why I am reclaiming the word agile to its original meaning, and distinguishing my meaning from the brand name of Agile by capitalizing Agile when I want to refer to methodologies called Agile that aren’t necessarily agile, and not capitalizing agile when I want to refer to methodologies that really are agile.]
Hi James,
>A problem I’ve had with some Agile advocates is when they also have a set of specific practices that Shall Not Be Questioned
I know what you mean. My take on it is that people are welcome to give a narrow and prescriptive definition of XP, as long as they don’t consider it a synonym for “Agile” (with our without the captial letter!). “XP is a subset of agile, not a synonym.”
I also think that the conflict between prescriptive and “open” interperetations of agile can be explained, to quite a large degree, by the Shu-Ha-Ri model of learning, which Alistair has mentioned several times in various books and articles. Essentially it says that there is value in precisely-specified processes, for people who are new to agile. However, experienced practitioners neither need nor want such a narrow framework, and perform better when they use their skills in a more flexible way.
It also says that, because the range of options are so wide, there can never be a precisely defined one-size-fits-all process (for the people who are new to agile). Instead, there will always be several (Scrum, XP, Crystal, DSDM etc). I think it this point that gets forgotten when certain techniques are held up as Not To Be Questioned.
[James’ Reply: I question the theory of precise specification for people of lesser skill. I think it may conflate two very different situations. In one situation, a supervisor directs a worker. Precise specification is made, but the supervisor is actively driving the system, as one might drive a car. The worker is serving as a tool for the supervisor. (The recent Mythbusters episode involving an unskilled pilot being talked down by a skilled pilot over the radio is an example of that.) In another situation, there is no supervisor, just a blind director. Precise specification is made, but the supervisor is not present, and neither is the driver, who is absent by virtue of being incapable of driving. The situations are very different.
The hope is that the combination of text-from-absent-skilled-person and unskilled-text-follower will result in a sufficiently competent control system. I think that never works in a cognitively complex process. Where it appears to work, I would look more closely, and I would expect to discover people actually are not following the text and actually applying their own skill.
Recipes can help unskilled people in situations where the necessary process is not cognitively complex. For instance, the process of starting my gas generator, or the process of resetting a circuit breaker in my house. (I almost wrote “the process of using a chainsaw”, but actually my experience with a chainsaw, recently, teaches me that even that is not a formulaic matter.)]
>Where it appears to work, I would look more closely, and I would expect to discover people actually are not following the text and actually applying their own skill.
So would I. I have always presumed that Shu-Ha-Ri, as applied to software development, did indeed require the “follower” to use their own skill. E.g. a Shu-style agile process may be useful to someone with a few years experience in non-agile processes, but probably unusable for someone straight out of college. Yes, relying on the skill of the “follower” involves some risk, but if you’re new to agile and you can’t find experienced supervision, what are you going to do?
[James’ Reply: What do you think I did when I was new to agile? I invented it. What did Kent Beck do? He invented it. How about Ward Cunningham? Invented it. How did Jerry Weinberg create the very first test team (for the Mercury project) in the history of computing, when there were no books to tell him how to do it? He just invented it. We’re not talking about how to build a scanning tunneling microscope, here. It’s not that hard. The means to experiment with ways of developing software are available to any of us. We’re all smart people or we wouldn’t be here.
People are not helpless.Â
Of course I got clues and help from other people. My very first introduction to paired programming was in 1990, when Randall Jensen gave a class in statistical SQA and happened to mention that paired programming was the single most effective way to improve programmer productivity (according to some study he had conducted). He didn’t tell us how to do it, but it planted a seed. That was enough for me to start playing with the idea.]Â
You want some kind of starting point, and there may be advantages in having an imperfect starting point that you can at least understand (Shu), rather than a better one which is too hard for you to understand (Ri). Anyway, that’s always been my interpretation of Shu-Ha-Ri as applied to software development. Ideally, we’d all learn in situations with adequate mentoring on-hand, but that’s not always possible.
In the ideal situation, the mentor would probably have a Ri-view of the world, but would try to package it in Shu-form for the “newbies” – inventing an “Shu” form which is appropriate to the particular situation at hand (which is something no book on agile can do!).
Finally, in practice, I don’t think any of this is ever quite as clear-cut as the simple 3 stage-model implies. However, I’ve still found the concept helpful.
[James’ Reply: It does sound helpful.]
Hello.
I was looking for a definition of Agile Methodology for an exams question; searching for the net, I fell on your blog. I think your definition is nice because after reading your def., I could now understand that of the book (modern systems analysis and design) which defines Agile Methodology as:
Motivated by recognition of software development as fluid, unpredictable, and dynamic
Three key principles
Adaptive rather than predictive
Emphasize people rather than roles
Self-adaptive processes
Thank you
Regards,
Ashesh
I thank all of you for useful comments.
Although I browsed the page to understand the simple definition while blog covers really insight thoughts about the methodology.
I was trying to understand the scope of being ‘Agile’ in Service Oriented Architecture or how SOA could serve agile methodology.
Best Regards
Ram Upadhayay
Agile methodology is criticized as it needs highly skilled developers. In case the team has average skills what problem do they face? what are the suggestions to limit scrum impediments faced by these developers?
[James’ Reply: It’s absurd to criticize a software development methodology because it requires skilled people. ALL SOFTWARE DEVELOPMENT METHODOLOGIES REQUIRE SKILLED PEOPLE.
Only fake software development can be done without skill. Yes, there are a lot of fakers out there. Don’t be one.]
Just a couple of moments ago I watched lecture on Agile Testing meeting Context Driven Approach and the speaker asked what is Agile?
As I never deeply investigated each approach of “Agile Testing” and I often try to quickly draw the principal idea behind something, I thought myself a very similar definition as yours.
“Whats agile? – Something that can easily change direction when needed – something flexible and adaptable.”
But I like Yours for being more explicit about objectives.
It happens lot when I listen to your lecture videos as well. And I enjoy that while I find basically same answers, yours are always richer of the experience and extra thought. Thanks for sharing.
[James’ Reply: Thanks!]