AGILE IN ACTION

While in New Zealand I came across this bar in Queenstown. Muda Bar in Queenstown, NZ Originally uploaded by sjb140470 . I've been an advocate of lean thinking for a few years now and it's good to see the techniques being applied in different domains. I particularly appreciate a pub eliminating waste from the beer-drinking process.

Things will go quiet around here from 5th February until the beginning of March. I'll be away in New Zealand and Australia. I'm not taking the PowerBook but I'll be taking a few books to read:

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 .

On Wednesday night Andrew Scotland ran a workshop at the second Agile Practitioners Forum. The event was organised by Les Oliver and Simon Voice and sponsored by Radtac and Connections Recruitment . The venue was the Gun Room aboard the HMS Belfast . The topic for exploration was bringing about the change necessary to accommodate the adoption of agile methods. At the heart of introducing agility into any large organisation is a huge amount of cultural, behavioural and organisational change. Andrew hypothesised that sometimes the need for this type of change is the primary driver for the introduction of agile methods and can be more important than the traditional drivers of improved ROI and improved engineering practice. Andrew provided a brief introduction that charted the BBC 's journey so far, where the introduction of Scrum (less focused on team behaviours and roles) proved more successful than the introduction of Extreme Programming (at that time more focused on engineering practice). The result is a prioritisation of the agile values where collaboration comes top. During the workshop, we will split into 4 groups to brainstorm factors that support change and factors that resist change. We then used a technique called force-field analysis to indicate the relative strengths of the factors.

Mihaly Csikszentmihalyi writes:

In a recommendation received from my last client I was described as a man on a mission to change the way the world thinks about [software product] development and teams, and to change the way software serves its purpose . It's true, but for some years now I've had a broader goal. I want to see the end of command-and-control because I don't believe agility can be achieved in a command-and-control environment. I believe that a working environment, which empowers people who are prepared to trust, show courage and make commitments, is capable of delivering so much more than an archaic, hierarchical and bureaucratic organisation that cultivates egos and politics. I want to help companies recognise the inherent problems with command-and-control . I want to help companies realise more benefits by helping them to: Flatten hierarchies and dismantle departments organised by role or skill-set, to remove bureaucracy and office politics and eliminate waste. Build cross-functional teams responsible for single products rather than spread that responsibility across groups of people taken from different departments. Overcome organisational constipation by pushing decision-making down to the coalface. Create, nurture and safeguard an open, trusting and empowering environment where everything is kept visible, where people can speak honestly, make commitments, be held accountable and demonstrate the courage to make decisions and take action, fail fast and learn quickly. Transform managers into servant-leaders who provide facilitation and let their team/s self-organise and decide how they will get things done. Get stuff done in a repeatable manner. Have fun. At the latest Agile Alliance board meeting members were asked to imagine what they would say if they were opening the Agile 2012 conference. I'm encouraged by the closing statements regarding the future of agile methods made by Brian Marick in his imaginary speech to open Agile 2012 :

Yesterday I read Matt Stephen 's article about the perils of pair programming . Let me prefix what I'm going to say with this: Pair-programming isn't for everyone. It's uncomfortable and scary at first. And when you're used to it it's intensive and bloody tiring. There's a gazillion reasons why people don't like pair-programming. Some people don't like the intensity of pairing. Others can't sustain the rate of interaction and burn out over time. There's no shame here. What is disappointing is that some people feel exposed when they pair, "the other person is constantly watching what I do and judging me!" They never quite grasp the fact that it's not about them. They're not being tested or judged. It gets worse when egos get in the way. Some people think they're a good programmer until pairing reveals that, actually, they ain't as good as they thought they were. And rather than take it on the chin, knuckle down and look to improve their skills by continuing to pair, they recoil and make some exclamation about why pair-programming is wrong. And then there's the variety of personal habits to contend with. Successful pair programming is as much about effective soft skills as it is about technical skills. Each person engaged in pairing needs to be sensitive to the other person, and listen effectively and read their body language; be able to convey ideas, engage in constructive disagreement, offer alternatives without judgement or condescension and persuade the other person; have the ability to sense when to offer help and be humble enough to ask for it. It's a shame many programmers struggle with these soft skills. Pair-programming is a social engagement, a conversation, an exchange of ideas between two people working together to solve a problem incrementally. It's both a technical and social learning experience. Having seen pair-programming work (and I do say, it works), I believe that the design cycle of test-driven development : test-code-refactor is simply more effective when one person is focused on tactical solutions while the other is continuously framing them strategically within the bigger picture of the system. Ok I haven't said anything new here, so back to the article. First, I want to make a general comment about the article. When I read it, I heard a lot about the individual and nothing about the team. I know the article is about pair-programming but the practice needs to be viewed within the broader context of achieving agility. And for me the concept of team is a key part to achieving agility. Matt starts with: