XP2012: The Extreme Challenge

"Agile has crossed the chasm" we hear often. But has it really? In the last few years Agile has gone from being "the cousin in the corner that shouts and screams but no one wants to talk to" to being "the famous cousin who everyones wants to talk to". It was not an easy transition, and to be sure there are still many in the Software industry that call that cousin the "bastard child" of software. Need an example? just take a look at the title of this book.

Agile has turned a corner, there's no doubt about that. However, we have also grown as community, and what was the focus of the last 5 years is also being challenged from within. J.B. Rainsberger described the evolution in a very critical as well as prescient way: the future of Agile is XP (the irony is not lost on many, I'm sure).

JB Rainsberger's keynote "The Extreme Decade: Progress, Pain, Paradox" from Agile Eastern Europe on Vimeo.

XP2012 happens in this context and in itself has a challenge of re-inventing the tired old format of Gurus coming to install the faith on the rest of us. Erik Lundh started a project for XP2012 that deserves some attention as well as exposure. XP2012 will be the first conference in a few years to live up to its name *because* of this challenge!

The XP2012 challenge!

The challenge is to do full cycle from Agilehttp://www.blogger.com/img/blank.gif Planning Game or similar to DoneDone deployed into production at least once in a week.

A set of teams of developers will be invited to attend the conference and effectively develop and release software at the conference in one week or less. They will start and end an iteration during the conference. Random people from the audience will use the software in the technical demos (not the team!) to check that everything is working.

So, if you work in a really good Agile team why not take the challenge? Come to XP2012 to *prove* that you can do Agile Software Development just as it should be done!

Photo credit: sanfora @ flickr

The "it's not my bug" anti-pattern

Talking to a friend we were discussing the organization of feature teams in a local company.

They were previously organized in component teams, which led to a lot of inefficiencies and disconnected work. This happened because one team would only work on one component, and when one feature required work in many components, that feature may not have been finalized at the end of the sprint, as one of the teams may have been busy with other work.

This highlights one of the problems that is common with component teams, they do not allow for an efficient allocation of work, as the dependencies increase between independent teams. You may still want to organize around component teams, but not if your goal is "efficiency".

But the anti-pattern that we talked about is actually when you have feature teams. If you have feature teams you will be able to assign one backlog item completely to one team, thereby reducing the dependencies between teams and potentially increasing the throughput of your program/group/unit/company.

However, there's a catch (there always is). You need to be explicitly clear about who fixes the bugs when nobody else wants them. The problem is this: when a bug is discovered during one iteration, it is likely that many teams may have touched the component that is the reason for the bug (assuming you can trace it). So, who takes it?

The anti-pattern tells us that the teams will *all* say that it is another team's code that is causing the problem, and nothing gets investigated which leads to many bugs crossing the iteration line and that should never happen.

How to solve this problem: you should state explicitly which team takes *all* the bugs under investigation. That way if the teams cannot agree on who takes the ball (in a Scrum of Scrums, say) there will be a clear owner for the investigation and potentially the fix.

Normally this would be the team that is assigned to "maintenance work" during that sprint, but you can decide otherwise if the maintenance team is too busy.