Do Agile Practices Make it an Agile Project?

Posted by Deborah Hartmann on Oct 17, 2006 06:58 AM

Community

Agile

Topics

Methodologies

Tags

Antipatterns ,

Criticism ,

Agile Manifesto

Use of Agile methodologies is growing, with recent surveys showing that approaches like XP, Scrum and FDD are being adopted more widely than ever.  There's a down side, however: Agile also risks what one practitioner calls "dying the death of a thousand copies," if teams copy practices rather than growing them, implementing what worked elsewhere without understanding how to use continuous improvement to make the process suitable for their own unique context.

RelatedVendorContent

Give-away eBook – Confessions of an IT Manager

Ensuring Code Quality in Multi-threaded Applications

The Agile Business Analyst: Skills and Techniques needed for Agile

Agile Development: A Manager's Roadmap for Success

The Agile Project Manager

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

Unfortunately, this "bad Agile" may be a natural side effect of increased popularity, and some will form their opinion of Agile software development based on these pale examples.  For example, in a recent essay called Egomania Itself (a clever anagram of "Agile Manifesto"), Steve Yegge picks up where he left off last month, complaining about Agile.  He uses the term "The Church of Agile" and likens Agile practice to superstition:

... there are probably some people who practice witchcraft to help their projects out, and a great many of those projects — probably the majority — wind up being successful.

If you do a rain dance for enough days in a row, it will eventually work. Guaranteed.

So I'm not saying Agile doesn't work. It does work! But it's plain, unadulterated superstition.

Certainly, Agile could be, and sometimes is, implemented in that way. However, this "faith-based" application of Agile practices - we believe this will work, we don't need to know why - ignores one of the most powerful tools used by Agile software development: reality.  Agile "embraces change" by applying empirical process.  Jim Highsmith, in Agile Project Management, describes it this way: "Agile projects are exploration projects, and as such, success depends upon reality-based feedback."  Agile's short  plan-do-inspect-adapt cycles are intended to increase understanding and so ensure that ineffective process not be repeated ad infinitum.  In fact, this inspect-and-adapt cycle could reveal to a team, under certain circumstances, that Agile is not what they need to use at all.

As Yegge asserts, even this form of Agile can work - but along the way there are stories of groups ordered to implement practices they don't need or want, teams hogtied with fixed date and scope and budget, and managers who strip developers of hard-won office space simply to get more done for less.  In these cases, even if they do produce working software, they are also producing angry and demoralized developers - and sometimes they're burning them out, too.  It's hard to reconcile this with the Agile Manifesto's first value of "people over process."

An interesting theme appeared in the conversation thread that followed on Yegge's blog page, talking about what makes the Agile practices work.  Here are a few snippets from that 10,000-word conversation - unfortunately, few commenters reveal who they are, so we're left to guess at who's saying what.

Geoff, aka "gilligan" warned Yegge against faulty syllogisms, and further wrote:

There is a type of person that I call an Agilista. Agilistas are nothing more than opportunists that have jumped on the Agile bandwagon and they shout "come down to the river and be healed". These Agilistas don't understand development, they don't know why Beck, Cockburn, Jeffries, Fowler, or whom ever suggest specific practices. These Agilistas don't even know what the real problems are! ...

When I first heard of XP I did some quick study of it and I started a paper. The title was "XP eXposed". I wanted the paper to be sound so I was doing my homework. As I experimented with XP I soon found that it wasn't as stupid as I first thought. Eventually I found that there were many good things to learn (for the novice) and to be reminded of (for the seasoned). I never finished the paper. Why? Because I found it better to focus on the good than to focus on the negative.

to which jiblet replied (in part):

These [agile and other] methodologies are the result of skilled developers refining their own process... The problem is: mediocre programmers won't get anything out of the methodology if they don't understand why. Otherwise it's just blind obedience without reason...

Cory Foy appealed to this same "return to the roots" approach, an idea he also talked about on his recent blog entry Principles, Not Processes:

It's a shame that what you've seen of XP has given you the impression it has. No matter how completely amusing your blog posts are.

Because, in my world of XP, one of the most important things for the teams to remember is that it is their process, not anyone else's, and it is their responsibility for ensuring that they understand the principles behind the practices so they can tweak them to fit their needs.

Agile teams ideally need to learn Agile Practices and Agile Values together, to make their process their own and to really excel.  The Agile Manifesto consists of four values supplemented by twelve principles. These are not suggestions: they define Agile software development, just as the Java api defines the behaviours of application servers that implement it.  The methodologies are simply different implementations, interpretations, so one would expect them to evolve and improve over time.

The four Agile Values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan ¹

Perhaps it's time to talk more about how failure to teach and practice these basics can lead to the the destruction of the most important assets a team has: the integrity, creativity and engagement of its members, and the trust of its customers.  It doesn't matter how many of the core practices a team uses - if their voices are stifled or ignored and their ability to produce real value is systematically obstructed, real agility probably isn't in the cards.

¹ The Agile Values form a portion of the complete Agile Manifesto, where its authors place these values in context.  It's a very brief document: if you've never taken the time to read it, please follow the link and have a look.

About the author

1. Back to top

   Examining the Agile Manifesto

   Oct 17, 2006 6:07 AM by Scott Ambler

   At http://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

   Reply

2. Back to top

   Inevitable Variation and Volume

   Oct 17, 2006 9:48 AM by Robert Martin

   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.

   Reply

3. Back to top

   Synergy of Values, Principles, and Practices

   Oct 17, 2006 7:01 PM by Robert Norton

   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 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. Pro? Contra?

   Reply

4. Back to top

   Re: Inevitable Variation and Volume

   Oct 18, 2006 7:21 AM by Deborah Hartmann

   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?

   Reply

5. Back to top

   Teaching Values through Practices.

   Oct 18, 2006 4:43 PM by Robert Martin

   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.

   Reply

6. Back to top

   Why Adopt One Practice Over Another?

   Oct 19, 2006 5:23 AM by Amr Elssamadisy

   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. Check out http://www.agilepracticepatterns.org for more thoughts on the subject. Amr Elssamadisy

   Reply

7. Back to top

   Re: Why Adopt One Practice Over Another?

   Oct 21, 2006 10:39 AM by Paul Oldfield

   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 , the work I did while I was learning my own new way of thinking, is found at: http://www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm

   Reply

8. Back to top

   Why should I care?

   Oct 24, 2006 7:45 AM by Bruce Rennie

   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.

   Reply

9. Back to top

   Understanding the Principles

   Oct 24, 2006 2:22 PM by Shane Mingins

   "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

   Reply

10. Back to top

    Re: Understanding the Principles

    Oct 25, 2006 7:49 AM by Bruce Rennie

    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.

    Reply

11. Back to top

    Gift economy

    Oct 27, 2006 9:23 AM by Deborah Hartmann

    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

    Reply

12. Back to top

    Re: Teaching Values through Practices.

    Nov 1, 2006 12:04 PM by Deborah Hartmann

    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

    Reply

13. Back to top

    Re: Teaching Values through Practices.

    Nov 2, 2006 10:15 PM by Robert Martin

    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.

    Reply

14. Back to top

    Re: Why should I care?

    Nov 6, 2006 1:08 PM by Jay Conne

    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.

    Reply

15. Back to top

    Reflections on the State of Agile

    Nov 15, 2006 3:20 PM by Deborah Hartmann

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

    ----- Brian Marick, independent consultant Mostly on agile methods with a testing slant www.exampler.com, www.testing.com/cgi-bin/blog

    Reply

• Older >