AGILE IN ACTION

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:

When people talk about Agile (with a capital A) organisations think "methodology for software development teams". This thinking gains credence when Agile finds its way into organisations through developers, as a grass-roots initiative, which is often the case. Taken alone, this adoption route is likely to fail, or at best, be severely hamstrung because the business and other organisational entities are not operating with the same values and principles. In supposedly agile projects, the values and principles break down in the wider business. Some organisations are unaware of this. And most aren't capable of addressing it because of habit, superstition and fear, inertia, and a lack of top-down support. Alarmingly, compromising the values and principles seems to be culturally accepted (and, in my opinion, endemic in the industry today). If the whole organisation cannot operate with shared values and principles, the technical investment becomes increasingly overshadowed by compromises made in the business domain. And it's these compromises that eventually cause projects to fail. These days I try not to say Agile (with a capital A). When I talk with companies I talk about "agility" and "achieving agility". For me, "agility" is the ability to deliver value to the business frequently, with quality software, and in a repeatable manner by leveraging the capability of empowered, disciplined, self-organising and cross-functional teams that are employing techniques based on the values and principles. While "achieving agility" is a continuous process of change which, to be successful, must involve the whole organisation. This post is based on one of many thought-provoking and enlightening conversations I have with Gus .

I value:

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 .

Since writing the original Agile Zealot's Handbook , Gus and I have had the chance to reflect on some of the wording. And Mishkin Berteig's recent generalisation of the handbook has prompted 3 minor editions: 1. We changed the title of TECH to QUALITY because delivering business value without compromising quality is achieved through the disciplined application of practices. 2. We modified the LEARNING text. We added reflection to inspection because it's one thing to look closely at something, but you need to think more deeply about it to reveal root causes and identify further actions. We also added re-planning as a specific activity that must occur at every iteration boundary, which along with adaptation and improvement, is based on what you learnt from the previous iteration. 3. Under TEAM, we felt a team also needs to be empowered to be creative because only when it has the freedom to be creative will it find better solutions by taking risks, failing fast and trying different things. So here's the new version:

'What's the difference?!'

It takes time and plenty of coaching to instil Agile values in someone, and help them develop Agile principles into an intuition to do the right thing . Also, there are many fuzzy, unpredictable, everyday situations beyond the scope of Agile principles and practices, which are governed by people factors such as mood, demeanour, intention, and motive, to name but a few. In these situations one should be guided by the Agile values to derive an appropriate course of action. Without experience, this can be difficult to do. For a team that is new to Agile, I really like the idea of having them set some Norms to be applied during the project. Conducted as a workshop at the start of a project, setting the Norms can help novices translate abstract values into concrete behaviours, without guiding principles. And, as a team exercise that results in consensus, the team can begin to bind around some simple, basic ground rules. Applying the Norms (or concrete behaviours) can help people to internalise the more abstract values. It's a good idea to keep the Norms big and visible , to serve as reminders, by posting them publicly around the workspace. I reproduced the original list of Norms referenced by David Anderson in his blog post, Where did the 40 hour week go? : Have fun! Honor time limits One speaks; all listen. Listen to understand Everyone participates; no one dominates It's okay to disagree Anyone can call a timeout Reaching consensus means that you're okay with a decision. It doesn't mean that you like it. It does mean that you agree not to talk down about it or quit over it. I discussed these Norms with a few colleagues and we liked them a lot. Here's a few additional norms we came up with: Be honest Learn from mistakes Take ownership and be responsible Commit publicly I'll run a workshop with the next team I coach to see what Norms they come up with.