InfoQ Article: Do Agile Practices Make it an Agile Project?
In this article, InfoQ's own Deb Hartmann responds to Steve Yegge's already-infamous Egomania Itself essay and gives us a frank discussion about how failure to teach the basics of Agile puts so much at risk: the integrity and engagement of team members, and the trust of their customers.
Read Do Agile Practices Make it an Agile Project?
Examining the Agile Manifesto
Practice Leader Agile Development, IBM Rational
Inevitable Variation and Volume
I am not particularly concerned about the variation of agile values within the industry. I believe in a free market of ideas, and think that the variations we see give folks the opportunity to try ideas that might be better than those formulated by the originators. I am confident that the values we have chosen will largely stand the test of time and inevitable variation.
You point out that some people are following agile practices blindly without understanding agile values. That doesn't bother me too much since following agile pracitces is a very good way to understand agile values. Often it is actions that come first and understanding that follows.
I think it's fair to say that all the agile methods, and the Agile Manifesto itself, were founded on values. I think it's also fair to say that those agile methods refined their value statements because of their practices. Indeed, I doubt the Agile Manifesto could have had such brevity and poigniance had it not been authored by folks who had struggled through the many different practices and methods. That struggle yielded the insight that led to the clarity of the values.
So, I think that agile practices and agile values are inextricably linked. That as you adopt one you also adopt the other with, or without, knowing it. And so I am not concerned that we need to increase our emphasis on teaching agile values. The variation in the understanding of the values is inevitable and healthy.
Something else that is inevitable is the Volume (i.e. loudness) of detractors. This is healthy since it is part of the free market of ideas. Were I a betting man, I would wager quite a lot of money that young Mr. Yegge's high volume detractions will fade away while the adoption of Agile Methods and Values continues to accelerate through the industry. His articulate, if uninformed, remarks don't bother me much because I think the free market of ideas will make it's choice intelligently.
Synergy of Values, Principles, and Practices
"Values bring purpose to practices, practices bring accountability to values. Principles bridge values and practices by guiding behavior. Practices by themselves are barren. Unless given purpose by values, they become rote."
OK, let's take an example.
Value: Responding to change over following a plan.
Principle: Welcome changing requirements, even late in development.
Adaptive planning methods
short, time-boxed iterations
which is enabled by
which are enabled by
which is enabled by
So if I use Cruise Control on my project, can it be said I value responding to change? Maybe I do and maybe I don't.
Continuous integration is an enabling practice that adds agility to the development process. If my team doesn't share the results of our frequent builds with our business stakeholders on a regular basis in order to elicit feedback, we're not involving the customer in the software process. We're thus endangering our ability to adaptively plan the course of the project in a way that meets the needs of our customers. This will inhibit the team's ability to respond to the changing needs and evolving understanding of the customers.
What if my team adopted all of the practices linked to adaptive planning? If we didn't value responding to change over following a plan, we wouldn't be using an adaptive planning method at the end of a short iteration or sprint to plan the next. So I agree with Uncle Bob that we've adopted the value "responding to change over following a plan", whether doing so was our conscious objective in adopting the specific practices in the first place or not.
So is our methodology agile yet? How about if our frequent releases only have a few high level tests and the code base is riddled with duplication and unnecessary complexity? Then we aren't following the principle of continuous attention to technical excellence and good design. This will also compromise our ability to produce working software. Expect our agility, i.e. our ability to respond to change, to suffer accordingly. And please note, Mr. Yegge, that my agility suffering is not the same as my soul suffering.
So, adopting the values and principles holistically, while still adding compatible ones to the set as XP and others have done, seems like a best-practice in adopting agile methods because it gives the team the ability to thoughtfully and effectively tailor the practices in their methodology to their needs over time.
Re: Inevitable Variation and Volume
Teaching Values through Practices.
If I had to choose one practice that would give a team the bigest kick-start towards agility, I would select short cycles. If you must deliver working software every week, you will quickly find that the stakeholders will provide more feedback than ever before. That feedback naturally leads to prioritizing features by business value, which leads to the planning game, which leads to measurement and burndown charts. These, in turn, lead to defining "Done", which leads to automated acceptance tests, which then lead to Continuous Integration. Continuous Integration can't happen without intense collaboration by the team, so it leads naturally to collective ownership and the beginning of pairing. The ability to run automated tests is infectious by itself. It enables refactoring, but is not sufficient if acceptance tests are the only automated tests. So TDD becomes important as the team wants ever more power to refactor. Intense refactoring increases pairing, which increases TDD, which...
The whole suite is interconnected. It's very difficult to adopt one small part of agility and not find that you need it all. And it is very dificult to adopt these practices without finding that you value what you have adoted. And that value quickly migrates to the agile values.
Why Adopt One Practice Over Another?
So, if the days of 'thou shalt do all 12 practices of XP' are behind us - which in large part they are - which practices should a group adopt? The answer I have found generally is "it depends!". We need to get beyond it depends to minimize the pains of incorrect adoption.
How do we do this? In my observations the most successful techniques so far involve bringing in someone(s) who have previous agile practice experience - either as a consultant or an addition to the team. Is there an effective alternative? I've read about successful 'bootstrapping' of agile methods but have yet to see them personally - they are a definite minority.
Is there an alternative? There has to be some middle ground. <Shameless Plug>Check out www.agilepracticepatterns.org for more thoughts on the subject. </Shameless Plug>
Re: Why Adopt One Practice Over Another?
We cannot expect any set of agile practices to work until we break this pattern. On occasion, kicking away the crutch of heavyweight process will cause such a shock when everyone falls in a heap that they will wake up, look around and change for the better. More likely they will start rebuilding their crutch.
Having an experienced person who understands agility and can change people's ways of thinking will help.
My own <shameless plug>, the work I did while I was learning my own new way of thinking, is found at:
Why should I care?
I tend to believe that there will always be those who will be tempted to adopt a new or different methodology without bothering to investigate the values on which it's based. This shouldn't come as any surprise since there's certainly ample evidence that there are others who will strive to ridicule or downplay a new approach, also without bothering to understand those same values.
In my view, neither of those groups should be our core concern, assuming we share a common goal in the first place. The unstated "Rule 0" of any methodology has to be "use your head". I suspect those that would adopt a methodology blindly are also likely not to understand that unspoken rule. We can't save those people, nor am I sure we should try.
In the same vein, I think we should stop worrying overly about the Yegge's of the world. Agile is not a trademark that requires defense.
Understanding the Principles
This reminds me of what Mary & Tom Poppendieck discuss (either in their talks or book) about how US car manufacturers tried copying the practices of Toyota, without understanding the principles behind them, and failed.
Re: Understanding the Principles
So, why do we react with horror when someone implements agile without understanding the principles? It's not our responsibility.
I also belong to a community where I have benefitted from what others have generously given away for free, and in return I contribute back, hopefully to make this community a good place to be. My contribution of an article to InfoQ is the same as anyone else's - i.e. uncompensated.
I do want to address your questions directly, I just need to find the time to formulate my thoughts... more later.
Re: Teaching Values through Practices.
In your suggestions for How to Use This Book you suggest different sections for different roles, but you propose that developers "read the book from cover to cover." This, then, includes Section 1: Agile Development, which you call "an in-depth discussion of agile principles and practices" in your Preface.
Bob, it looks like you've put the Values and Principles in front of the reader right up front, as do I when teaching. By the way, I totally agree with you that these are not canonical (i.e. cannot be modified or augmented).
So, is it possible we're in violent agreement?
Re: Teaching Values through Practices.
I think the only thing we disagree about is that it's worth making a fuss over Yegge's FUD about of "Bad Agile". I think the practices, principles, and values are valuable, worth teaching, and self-reinforcing.
Re: Why should I care?
In my Agile/Scrum coaching and training I add to the standard list of practices and principles, "Independent Thinking" as a team member. "You are paid for your brain not just bit-shoveling. Your self-respect, integrity and professionalism require that you speak up on any issues that effect your ability to deliver value."
Of course it's easy for me to say - getting people to accept that responsibility is another thing. As a coach, I can encourage it and hopefully get the team's management to support it. I have been wrong!
A necessary precondition is team safety to "pull" ideas from them. When management pays it lip service and then balks at the systemic problems revealed, it creates a whole new challenge.
I do think it's valuable to answer detractors as an excuse to keep the issues visible as the world is learning to respect our approach. I don't think we have reached the point where we can just ignore the detractors.
Reflections on the State of Agile
To my mind, there are three issues with Agile:
1. It's a way of making the institution treat the individuals better. That's a lot of what he's referring to when he talks about Good Agile.
2. It's a way of getting individuals to treat *each other* better. As a testing consultant, that's a lot of what originally attracted me to Agile: there was a possibility of less "I'm so much smarter than you because I know what closures are" attitude toward testers and the people paying the bills. He's taken a familiar rhetorical style in his pieces that works well for his audience, but the question it raises in my mind is whether that style bleeds over into his personal interactions. If so, he could *in many teams* be optimizing his own personal performance and pessimizing the whole. In a place like Google or the old Microsoft, that wasn't such a problem due to the people they hired; in many places, it is.
(Just as an aside: the bit about "tearing up the index cards" may be an effect of the focus on the individual programmer. I haven't seen any huge benefit to index cards in my individual work, but I've twice seen the use of index cards instead of spreadsheets, etc. act amazingly well to streamline things.)
3. By shifting the programming constraints (change more than you want to, more often than you want to, deliver frequently, develop in small slices), it forces people to approach programming differently. Many craftspeople have said that creativity is fostered by constraints. For example, one poet I know says that part of the benefit of rhyme schemes and meter is that it often prevents you from choosing the obvious word. When you choose a different word, sometimes you realize that you've been expressing the obvious thought - so it forces you to think again. That's what I find the Agile constraints doing for my own programming. Once I'd learned to deal with those constraints, I could have gone back to what I used to do, but I chose not to. The constraints work well for me.
And we shouldn't forget the typical boom and bust cycle of mindshare. There always seems to be over-hyping, followed by over-criticism in response, followed by a settling to equilibrium once the enthusiasts and counter-enthusiasts find another field of battle and leave the quieter people alone to figure things out. That happened with object-oriented programming. However, the boom can lead to a permanent bust, as it did, for example, with Lisp and AI.
Brian also included his notes on a familiar Ghandi quote:
"First they ignore you, then they laugh at you, then they fight you, then you win." Ignore was around 1998, probably; laugh at was around 2001; now we're possibly in the middle of the fighting part (where a part of the enemy are the people who want to commercialize the form of Agile).
Brian Marick, independent consultant
Mostly on agile methods with a testing slant