AGILE IN ACTION

In the last Agile Practitioners Forum there was a debate about why there is a need for organisational change when using agile methods. At least 2 people were arguing that there isn't a need to bring about change outside the project. The majority, however, were saying that there comes a time when the wider organisation becomes a constraint and inhibits a project team's ability to improve further and achieve higher levels of quality and throughput. A bugbear of mine, and I've been harping on about it again and again and again , is how many organisations restrict adaptation to how they practice agile methods. Some practices are used and not others, principles are ignored or compromised, values are not understood and little is done to establish an ecosystem in which project success can be achieved. They refuse to entertain the idea that the organisation needs to adapt too . As George Dinwiddie says: Organisations want the benefits of Agile, but they don't want to give up the cubes and solo development work. They don't trust the team to self-organise and create valuable software, so they stick with organisational frameworks that prevent the very things they fear won't happen. One of Brian Marick 's themes about agility is that it's about acting to change the context more than it is about adapting to suit the context . Inevitably there needs to be some local adaptation because agility is in constant interplay with its environment. But organisations need to empower the people doing the work to ask themselves "what should I change about my environment that would enable me to work better?" and then take the necessary actions to bring about that change. When an organisation is trying to achieve agility, restricting change to just the project imposes a glass ceiling on a team's ability to get better. This is effectively capping human potential and that can't be good for the organisation going forward.

I've decided to take a plunge and have proposed a session for XPday . It's a world cafe version of the open discussion about Compromised Agility that I ran at the inaugural Agile Practitioners Forum . The aim of the proposed session is to debate whether adaptations that compromise values and principles actually degrade a team's agility, impacting their ability to deliver successfully. It would be appropriate for anyone who is working, or who has worked previously, with agile methods regardless of their level of experience. Here's the description of the session:

Via InfoQ , Jason Yip Tobias Mayer recently described some successful adaptations he's made to Scrum . Jason Yip summarised: Don't separate the technical and non-technical members of the team. Shorten iterations (1 month is too long) and focus on end-to-end cycle time. Use smaller tasks instead of task estimation. Make tracking visible in the workspace. Quality engineering practices are not optional. Process leaders should make themselves unnecessary. I totally agree that 1 month is too long for an iteration. When I first started doing Scrum, we used 30-day sprints and I quickly saw student syndrome set in. We tried 2-week iterations and had some improvement but I still saw people take their foot off the gas in the first week and then struggle to make it up in the second week. You can't beat 1-week iterations . They force everything to be smaller. Complexity is broken down by smaller user stories and they can be estimated with less inaccuracy. A great visual indicator of progress is a steady rise in running tested features as stories hit the done column every day. Planning games are shorter because you do less in a week. And by the time you start you need to be thinking about finishing because iteration reviews come fast, so communication is more intense. You get to inspect and adapt every 7 days, and celebrate success 4 times in a month as opposed to once. And this builds momentum . I don't like planning with tasks because, when user stories are small (typically 1 to 2 days of effort), tasks belong to the developer-pair. They form a 'private' to-do list that reflects how the developers will get the story done. Planning and tracking these tasks is micro-management. These adaptations do not compromise agility . They amplify it. I'm not sure that the Scrum Master role isn't always necessary, though. I agree that the coaching/process-leader role can become redundant when a team achieves the ability to self-organise. But the facilitator role that the Scrum Master also fulfils remains important even within a self-organising team .

Back in December, Mike Griffiths devised an Agility Assessment Quiz . I was interested to see the agility-profile for the team I've been coaching recently. We came out as uber agile . You can see my answers to the questions and read an account of our team practices and successes here .