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?!'

The principles of agile methods such as Extreme Programming and Lean Development are simple rules that govern behaviour. They guide practices and facilitate decision-making at the 'coal-face' rather than restricting it to the management echelons of an organisation by providing a framework that enables experienced agile developers to make intuitive decisions quickly without having to wait for instructions or permission. An experienced agile software development team is a highly social group that is self-organising around these principles and acts with coordination and collective behaviour. This collective behaviour comprises: Collective mind [1] where individual team members develop shared understandings of the team's tasks and of one another, and come to understand how their work contributes to the work of the team thereby facilitating team performance. Swarm intelligence which gives a team the ability to adapt to changes, and robustness which enables them to still perform and deliver even when one or more members fail. Extreme Programming principles: Humanity : Acknowledge human frailty, leverage human strengths, and balance individual and team needs. Economics : Enhance the option value of the software and the team while remembering the time value of money. Mutual benefit : All activities should benefit everyone. Self-similarity : When something works in one context, try it in another. Even if it eventually doesn't work, it's a start. Improvement : 'Perfect' is a verb and not an adjective. Always seek to improve. Diversity : The team should comprise people with different backgrounds, skills and perspectives. Reflection : Think about how you're working and why you're working. Flow : Deliver a steady flow of business value by engaging in all activities simultaneously. Opportunity : See problems as opportunities for change and learning. Redundancy : Don't be afraid to include redundancy, e.g. a distinct testing phase after development, if it helps prevent disaster. Failure : If you're having trouble succeeding, don't be afraid to fail. Quality : Always push for higher quality. Baby steps : The overhead of small steps is less than when a team wastefully recoils from aborted big changes. Accepted responsibility : Responsibility cannot be assigned. It can only be accepted. Lean principles: Eliminate waste and spend time only on what adds real value for the customer. Amplify learning and increase feedback when facing tough problems. Decide as late as possible to keep options open as long as practical, but no longer. Deliver as fast as possible , aiming to deliver value to the customer as soon as they request it. Empower the team so that people adding value use their full potential. Build integrity in , don't try to tack on integrity afterwards. See the whole , don't optimise parts at the expense of the whole. References: [1] K. Weick and K. Roberts, "Collective Mind in Organizations: Heedful Interrelating on Flight Decks," Administrative Science Quarterly, 357-381 (1993).