I'm reading Lyssa Adkin's
Coaching Agile Teams book. It's a fine book and fufills an important niche.
Yet every time I pick it up, I get a ... vibe. I think it's that Lyssa uses the term Agile so much, but never really defines what she means by the term.
That's okay, I suppose - the introduction explains this is an advanced book, and the readers should be familiar with the definition of "Agile." Still, go to any conference and ask ten people to define 'Agile' and you'll probably get eleven answers. (Twelve if you count yourself.)
A few chapters in, I think I understand where Lyssa is coming from. When she uses the term Agile, she means an integrated, multi-disciplinary, self-organized project team. The kind where the customer tells you the problem, and you figure out the solution and make a commitment for delivery. (Ideally, the customer is on the team, right there with you.) The most common alternative to this is command-and-control, where someone, often technical management, tells the team exactly what to do, when to do it, and how to do it.
On a command and control project and "good" is defined more in terms of completion of the plan or adherance to process than in terms of a good outcome for the customer. (Under command and control, teams are usually organized by technical discipline, not project, and they are often encouraged to compete against each other.)
This is a very
Scrum-ish definition of Agile, but it's a perfectly good one.
If you'll let me, though, I would like to offer to elaborate on that a bit, to offer my interpretation of the
Agile Manifesto:
We are uncovering better ways to develop software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more
Where did the obsession on the stuff on the right come from?
The authors of the Agile Manifesto were clearly reacting to some sort of management ideology that focuses on the stuff on the right, yes?
Now think about who they were: Kent Beck, Ward Cunningham, Ron Jeffries, Jon Kern ... these are technical guys with a programmer's perspective. Even Alistair Cockburn, the project management Guru of the Conference, and Brian Marick, the token tester, started their careers as programmers.
Is it possible that the authors of the Agile Manifesto were saying something like this:
"Hey, you people-people with the documents and the templates and the slavish process and the pathological box-checking. Yes you! All that time we spend on those things is time we are not actually building or testing software. Tell you what. We are the leaders in our field. We think we've got how to develop software figured out -- at least, that we've got techniques that deliver value quickly and provide customers the means to steer to the outcome they want. So how about this: Let us work with the customer directly. Leave us along for a couple of weeks to a couple of months at a time. Then we'll provide the customer something that works, and they can select what to build on the next increment. How about that? Hey, tell you want - we'll call it 'Agile'!"
Just ask yourself -- is it possible?
Think not? Let's scroll down the page and click through to the twelve principles of Agile Software Development. Let's look at a few of these:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
These all say something similar: Let us figure out how to do it. Trust us to do it right. Measure us by what we deliver. Don't force us to create a document we don't see value in.
Why is this important
Consider all the conversations in the world about is this-or-that process Agile or not. This isn't Agile, that isn't Agile, blah blah blah. Sure, there are certainly things like Big Agile Up Front that take whatever we were doing before, add terms like 'iteration' or 'story', and don't really change themselves.
But i'm not talking about that. Nor am I talking about a team doing whatever-they-feel like and calling calling it 'Agile.' Pure chaos can work for some one-man bands writing novels, but I wouldn't want to develop software that way.
What I am talking about is a team working to deliver software in reasonably small increments at a sustainable pace. The team decides by itself how to develop and deploy the software, and they periodically meet to review how things are going, to discuss the consequences of those decisions, inspect and adapt.
Such a team can still get a lot wrong, and they can certainly have room for improvement. They may greatly benefit from technical practices or training -- and you may be able to call such a team a lot of things.
I'm just sayin', #notagile ain't one of them.
Conclusions
Next time you are talking to someone or reading an article about 'Agile' software development, 'Agile' testing, 'Agility', or this-or-that process, consider the meaning of Agile offered here, and ask yourself if the two are compatible.
The pull of the things on the right is strong and, sometimes, invisible. Let us all be champions for the things on the left, shall we?