The Collective Agile Discussion

I am both encouraged and disheartened by what I am hearing on the the subject of Agile these days. I got a large dose of the discussion in conversations and lectures at Tech Ed this year, and the blogsphere resonates with it every time you turn around.

The Encouraging

Dialog is beginning to focus on Lean and iterative delivery practices. These basic values supported by the Agile manifesto are beginning to receive more attention, much to my pleasure. We are finally getting around to talking about value flow rather than our available hodgepodge of Agile coding techniques. Excellent!

Scrum has finally been recognized as an excellent team management model that supports Agility. It is also prone to fracturing at large scale and must be held together with more pressure at large size. It takes more than Scrum to deliver on the whole promise.

Test Driven Development is a wonderfully Lean practice that has genuinely matured to a standard engineering practice. Who can argue with, “Constant attention to quality?” Now that we can agree this is how to do business, we are simply evolving the technique rather than arguing about whether it has value. Good stuff.

The Exciting

Agile practices and Lean techniques are finding home in even the stodgiest organizations. Few developers would dare admit they aren’t “Agile”. Sometimes it is even true.

The Microsoft team building Rosario is executing their work in a genuinely Agile way. That is, iterative with high visibility and close client involvement. The ASP.Net MVC team is behaving similarly with frequent releases and high bandwidth feedback from the community.

The Discouraging

Many people describing their Agile practices center around the common denominator of, “No requirements and we work on the highest priority item.” That’s firefighting. Agile requires the discipline of focus, if only for a single iteration.

Implementing only a few practices that seem easy to accomplish does not make an organization Agile. Yes, iterations are important, but they are not the end game. Steady delivery of genuine value is the end game.

I cannot count the number of times people have represented their practices as “Scrum-like”. I commonly ask, “Did you start with Scrum and modify it to fit your shop?”

“No,” is the common answer. “We read the books and picked the parts that seemed to make sense for us.”

That really bothers me because if there is one thing I have learned in the last 5 years of implementing Agile practices, it is this: Practice the prescriptive Guidance for 3 months before you change anything.

We all think we’re different, but we struggle with the same issues. There are very real recipes for these techniques. Agile is a lot of things, but it isn’t just what you want it to be.

6 thoughts on “The Collective Agile Discussion

  1. “Practice the prescriptive Guidance for 3 months before you change anything.”

    I don’t agree. This is often just not possible.

    How am I supposed to apply the standard 4-week iterations of Scrum when all of my projects only last for 3 weeks on average?

    How am I supposed to apply the 5-9 team members rule when I have a team of just one person?

    I have blogged about this in “Copy-Paste Reasoning (or Adopt, Skip Adopt)”
    http://www.noop.nl/2008/06/copy-paste-reasoning.html

  2. Most Scrum teams and practitioners have settled on 2 week iterations, btw. Scrum does not dictate length of an iteration.

    A team of one? That isn’t a team and as such has no need for a team management model like Scrum, XP, Chrystal, or anything else IMO. I also find myself working on individual projects and without team mates quite often. In those times, I do not use any formal process other than my own to-do list.

    Now ask this, “How can I truly excel in a vacuum?”

  3. Most Scrum teams and practitioners have settled on 2 week iterations, btw. Scrum does not dictate length of an iteration.

    A team of one? That isn’t a team and as such has no need for a team management model like Scrum, XP, Chrystal, or anything else IMO. I also find myself working on individual projects and without team mates quite often. In those times, I do not use any formal process other than my own to-do list.

    I would also argue that even in this situation, the focus can and should remain on value delivery. I can be Lean all by myself.

  4. “Most Scrum teams and practitioners have settled on 2 week iterations, btw. Scrum does not dictate length of an iteration.”

    Yes, most Scrum documents talk about 30-day sprints. It’s in Ken Schwaber’s books, it’s on his web site, etc.

    http://www.controlchaos.com/old-site/rules.htm

    So you see, you’ve just proved my point…

    Many people think it’s better not to do 4-weeks sprints but 2-week sprints. Why should we start with the rules of the book, when we know that doing something else is better in our situation?

  5. OK, fair enough. Guess how we figured out 2 weeks was right? We followed the prescription and changed from there.

    In a broader sense, though, why am I supporting following the guidance? Because without experience, changing the recipe has a much higher risk of creating a bad dish. That’s all.

Comments are closed.

Proudly powered by WordPress | Theme: Code Blog by Crimson Themes.