Do Agile Practices Make it an Agile Project?

At www.ambysoft.com/essays/agileManifesto.html I have a fairly detailed write up discussing both the values and the principles described in the Agile Manifesto. Too bad Steve didn't take the time to read something like this.

- Scott
Practice Leader Agile Development, IBM Rational

Deborah,

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.

I think Kent Beck said it best in Extreme Programming Explained, 2nd Ed. I quote an abridged version:

"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.

Practices:

Adaptive planning methods
   which require
short, time-boxed iterations 
   and 
customer involvement
   which is enabled by
frequent releases
   which are enabled by 
continuous integration
   which is enabled by 
automated testing

So, Bob... in order to teach the values VIA the practices, does it matter which practices they use? Or can they use any combination of practices?

I think agility is infectious. At Object Mentor we have helped many folks who had previously adopted Scrum, to subsequently adopt TDD, and Continuous Integration, and Automated Acceptance Testing. I think the reason for this progression of practices is that the practices and values form a weave that gradually leads teams to adopt the whole of agility. Just adopting one practice can cause a shift in values that makes another practice easier to adopt.

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.

Uncle Bob's comments about practices as a way to understand agile values is well taken. Unfortunately the wrong practices, or the practices incorrectly adopted and/or adopted (in context) usually do not lead to understanding agile values. In fact the lead to misunderstanding, failure of adoption, and dropping of the practices.

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>

Amr Elssamadisy

There seems to be a 'traditional' school of thought about process that leads people not to think about what they are doing or why. I'm sure this isn't explicitly taught, but often enough it's what happens.

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:
www.aptprocess.com/whitepapers/risk/RiskToPatte...

Ok, so there are lots of people adopting agile practices for what might be the wrong reasons. I'm having a bit of difficulty understanding why I should be concerned.

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.

"if teams copy practices rather than growing them"

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.

Shane

I'm pretty sure that the Japanese laughed their asses off when it happened too.

So, why do we react with horror when someone implements agile without understanding the principles? It's not our responsibility.

Bruce, your points about "responsibility" and "concern" seem to point up an aspect of what I'm doing here: I do have a day job, where I have "responsibilities", and where my "concerns" are relatively clearly delineated.

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.
deb

I've just started reading Agile Principles, Patterns and Practices in C# (by Bob Martin and Micah Martin :-) Upon opening the cover, I see the Agile Manifesto (with the 4 Values) on the flyleaf, and on the facing page, the Principles behind the Agile Manifesto.

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?

:-)
deb

Deborah,

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.

Bruce, I agree with your "Rule 0" and your description of the casual defensive detractors of the new.

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.

Brian Marick sent me these reflections, with permission to post them here.

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).