[ Content | View menu ]

The Trappings of Agile

Mark Mzyk | November 9, 2011

It’s easy to think that the agile movement has been around forever. It certainly feels like it has in the raging torrent that is software development time. Yet if you read the Agile Manifesto that started it all, at the bottom, in small letters, you’ll notice the copyright date.

© 2001.

Only ten years ago the agile movement formally started. I’m sure it was around informally before then. Now it’s an institution that is embodied in methodologies and programs from XP to Scrum.

It good to read the manifesto that started it all. To see the simplicity that launched a movement. Because overtime, as is human nature, we keep adding on facets, until we forget what the original item looked like. This can be for better or worse (think a person from the 50s would recognize a TV today as a TV, if it wasn’t on?).

One facet we’ve added is the concept of velocity. Jim Highsmith details nicely how the concept of velocity has been stretched so it chokes the agile process. A key quote:

Compounding the problem, the Agile movement has focused on high levels of customer involvement—basically a good thing—but we’ve gone too far. A large number of Agilists decry that they can’t get organizations to focus on technical practices—but why should that be a surprise when we encourage product managers/owners to make all the priority decisions and then measure performance using velocity?

This point is spot on. In my experience, product owners are often given complete control over priority, so technical optimizations or necessary muck work aren’t prioritized. Going back to the agile manifesto, read over the names of the original signers. They all have experience in the technical and the business sides of the equation. They intuitively know how to balance both. Now that agile has gained widespread adoption, teams do not necessarily have this experience.

The idea of the self organizing team needs to return to the agile movement. The team doesn’t have to be self organizing in that team members constantly change. That becomes too disruptive. The team needs to be self organizing in that the team picks the order of the work they will complete. The product owner might set priority, but it is the team that takes on the work and the order they complete it. There is obviously back and forth between the team and the product owner, but as the manifesto says: people over process. We trust that the team will organize itself, taking into consideration the wishes of the business, so that the work gets done as quickly as possible with the highest quality.

I think people often forget that agile is not a rigid system to be followed. It is simply a belief that change is constant, so we should favor a way of doing things that makes change easy.

In short, do what works for you so that you develop quality software on time. That’s the definition of agile, with all the trappings stripped away.


And so development starts / CC License