Choosing an agile process – Part 3: Evaluation

Thursday, January 10, 2008 – 9:57 AM

So now we’ve established that designing your own process from scratch is a bad idea you’ll notice that the name of this thread of posts has changed slightly. Once you’ve decided to “buy” a process you still need to evaluate it. Is it a good fit for your organization?

The key thing here is does an agile process and the values it holds dear fit in with your organization or team’s? If the values seem to fit how do you apply them, in the form of principles, to your organization?

Values – Abstract, distinct ideals. For example XP’s values are; courage, communication, feedback, respect and simplicity (Extreme Programming Explained, edition 2 added respect).

Principles – Are values as applied to your problem domain or industry.

Practices – Practices are the principles applied to your team.

You can think of principles as the bridge between abstract values and concrete principles. For example the value of communication leads to the principle of placing emphasis on the whole team – thinking of teams as more important than individuals – which in turn leads to practices like an open team workspace and collective code ownership or daily stand-up meetings. Extreme Programming Explained, edition 2 goes into all this in some detail and is well worth the read.

In reality values are sufficiently abstract that most people will think they agree on them, at least initially. It’s hard to find someone who will say that that communication is a bad thing, what differs is how they choose to apply it. For instance I might decide on the principle of individual rock star developers leading surgical team. Here communication is optimized through one individual, as documented by Brooks in The Mythical Man Month. Then I might have practices like; the surgeon (rock star) works alone and has daily meetings with their individual team members and the surgeon’s copilot (junior developer)  is always available to meet with other dependent teams. Caveat: I’ve never tried this approach, it’s simply a counter example.

As the surgical team example illustrates practices are very concrete, we agree on communication but when I describe my surgical team to you it’s a far cry from your ideal of a Scrum team. Your team sits in the same room working together on a problem with equal ownership of the work. Clearly our values may seem to align but our principles and therefore practices do not.

Our current approach has been to start with the XP values and then work on the principles and practices from there. When people differ significantly on practices and principles map back to the values and ask the question “Do we really value this in the same way or not?”. This is where things start to get interesting… How do our principles differ? The more misalignment you uncover the less likely a process adoption is to succeed.

You can use this to evaluate your buy decision based on the values, principles and practices fit of various methodologies, process or frameworks. Most agile processes embody fairly similar values, as summarized by the agile manifesto, but are more or less prescriptive when it comes to values. Scrum is really a project management framework with no practices related to the actual writing of software. XP on the other hand is much more focused on software development and defines a set of practices for developers.

You can make alignment easier across your organization by picking a process that’s an easier “sell” because it’s less prescriptive, like Scrum, or aligns to some of your existing practices. There is significant room to maneuver here. If you uncover a significant misalignment in values across the organization then this spells big trouble.

“People only change their values in light of a miracle or near death experience” – Bob Brumfield

Obviously one could try and arrange the latter but I’m certainly not going to tell you how. Don’t expect people to change their values, they probably will not.

Adopting a new agile process may cause those who don’t share the values behind your new way of doing things to leave the team. In my experience this is never as bad as you think. I’ve seen teams struggle week after week until their star developer left only to be replaced by someone completely new to the product. The predicted outcome of “we’re doomed” never materialized, without the disruptive value misalignment the team gelled and exceeded our expectations. When XP says it requires courage this means management also.

Technorati Tags: ,,

  1. 1 Trackback(s)

  2. Jun 15, 2008: #2782 » Blog Archive » Choosing an agile process - Summary

Sorry, comments for this entry are closed at this time.