Are we agile?

Just what is agile? Let’s see how the Metro dev team fares against the agile manifesto.

1. Individuals and interactions over processes and tools.

We definitely emphasize individuals and interactions. Everyone on the dev team gets a say in what we do – from our product roadmap to the technical nitty-gritty.

We have daily standups to make sure we’re all on the same page. We have a culture of developers helping each other.

2. Working product over comprehensive documentation.

We typically do several production releases a day. We have minimal documentation – we prefer to share knowledge by working together.

3. Customer collaboration over contract negotiation.

We are the driving force behind our twice-weekly “product standup” with the other teams (content, UXD, commercial, etc). We sit with the content team.

We believe that our product is constantly evolving. We constantly seek feedback, rather than trying to get work “locked down”.

4. Responding to change over following a plan

Our two week focuses make it easy to adapt – we seldom commit to more than two weeks work. We generally have some space for “business as usual” work as part of our focuses.

We’ve slotted in important work (such as SEO and newsletters) as other key teams become available to collaborate on it.

What about the twelve principles of agile?

We disagree with two of the twelve principles. First, here are the ten that we’re true to:

Our highest priority is to satisfy the customer through early and continuous delivery of a valuable product.

Welcome changing requirements, even late in development. Agile processes harness change for the businesses competitive advantage.

Deliver a working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Here are the two principles we DISAGREE with:

“Working software is the primary measure of progress”

We DISAGREE with this. The primary measure of progress is business value. For example…

We increased the number of related posts from 4 to 6. In terms of working software there was very little progress but in terms of business value there was BIG progress (a 3% increase in clicks).

“Continuous attention to technical excellence enhances agility”

Our attention to technical excellence is not continuous. We sometimes release messy code and tidy it up once a new feature has proved successful.

(We keep it simple though, so tidying up isn’t a big deal. For example, our new polls API is around 30 lines of code.)

Plenty of the features we add aren’t successful. We believe in “fail often, fail fast”. Personalization for example was a long shot that didn’t pay off.

Conclusion

Metro dev team is highly agile. There are a couple of principles where we’re “lean” rather than “agile”. I always wondered what the difference was!