AGILE IN ACTION

Well, we did our XPDay session: Have you compromised your agility? The run-up to the conference was a bit manic because we thought XPDay was a week later than it actually was. Our thanks go to Steve Freeman for spurring us into frantic action. We burnt the week rushing around buying props (coloured table cloths, battery powered candles, lollipops, etc), preparing posters and handouts, and putting together a chilled-out music playlist. We pretty much knew what we wanted to say in the session but it was delivered mostly on a wing and a prayer. Despite me getting over a cold and Gus being hungover, we thought it went reasonably well and we had lots of fun. There must have been around 60 people in the cafe, probably twice the ideal number, but it went smoothly enough. More people arrived, some turned around because we were at capacity on the tables, others stayed and formed a circle on the floor. We wanted to do the session because we're worried about the state of affairs. We're seeing more organisations trying to be agile but, when you hold them up to the light, the standard is often poor. Agility is being compromised for corporate fit. We want organisations trying to be agile to raise their game. There needs to be both organisational change and cultural change. And we want people to expect better and do more. We think arguments about dogmatism versus pragmatism, or one approach over another, detract from the real issues: Organisations value the wrong things. People do not maintain a high-level of craftsmanship. Organisations adapt Agile for corporate fit rather than to improve. People accept mediocrity to maintain the status quo rather than strive for excellence through continuous improvement. Organisations focus on efficiency and don't worry about achieving effectiveness first. People are not empowered to do the right thing. Agility is partly about process and practices, and these are the parts that organisations typically latch onto, but its capability is rooted in the culture established by the values and principles and peoples' behaviour. These are often in conflict with the organisation. In the session, each table was given a real issue to discuss. A mind-map for each issue provided a 'starter for ten' and was used to spark a debate. The IT industry is perennially failing 'the business' and while there's no silver bullet, agile approaches can, at least, help us make improvements and do better. Our aim was to hopefully raise awareness of declining standards and inspire people to help us raise the bar. I've included the mind-maps and doodlings. The debates were engaging and pretty intense and consequently it's difficult to distill too much from the doodlings. 1. Misplaced values? value-mindmap Originally uploaded by sjb140470 value-output-1 Originally uploaded by sjb140470 value-output-2 Originally uploaded by sjb140470 value-output-3 Originally uploaded by sjb140470 2. Adapting for fit? adaptation-mindmap Originally uploaded by sjb140470 adaptation-output-1 Originally uploaded by sjb140470 adaptation-output-2 Originally uploaded by sjb140470 3. Accepting mediocrity? excellence-mindmap Originally uploaded by sjb140470 excellence-output Originally uploaded by sjb140470 4. Doing the right thing? conscience-mindmap Originally uploaded by sjb140470 conscience-output-2 Originally uploaded by sjb140470 conscience-output-1 Originally uploaded by sjb140470 5. Is the process adding value? process-mindmap Originally uploaded by sjb140470 process-output-1 Originally uploaded by sjb140470 process-output-2 Originally uploaded by sjb140470 6. Managed or led? leadership-output Originally uploaded by sjb140470 Only 15 people left feedback but it was the last session on the last day and everyone wanted to get to the pub. The feedback was overwhelmingly positive. 13 people said "they loved it" and that it was "a great format with interesting topics"; 2 people said it was "a good session"; nobody said they "wouldn't recommend it to others". Here's the poster show and here are some photos of the event: The Conversation 'World' Cafe Originally uploaded by sjb140470 Half the room Originally uploaded by sjb140470 Discussing when adaptation compromises Originally uploaded by sjb140470 Discussing valuing the right things Originally uploaded by sjb140470 Discussing excellence vs accepting mediocrity Originally uploaded by sjb140470 Circulating between tables Originally uploaded by sjb140470

Our session - Have you compromised your agility? - has been accepted for XP Day . I'm surprised though because there wasn't a great deal of wiki-discussion about the session during the selection process. I know Steve Freeman championed the inclusion of our session and so our thanks go to him. Hopefully it will contribute to a provocative and constructive end to the event that will see the debate extend to the pub afterwards. The plan is to roll our session and Steve's session - Have we lost our mojo? - together to discuss the notion of compromised agility and raise questions about the current state of the Agile community. I couldn't resist creating a poster with a version of our handbook . We plan to make these available for sale and we might even have a few at the conference. If anyone is interested in purchasing a poster, please send me an email at simon at energizedwork dot com. dont-compromise-your-agility Originally uploaded by sjb140470

On the first day of the Agile Business Conference , Roman Pichler talked about the Role of the Agile Product Owner. It was a succinct presentation of the basic responsibilities of Scrum's Product Owner role. Roman conveyed the likelihood that the Product Owner would not be available all of the time (he mentioned hot-desking) nor be colocated with the team. He showed a hypothetical calendar day for a Product Owner that had an hour blocked out in the morning dedicated to collaboration with the team. This set-up is a reality for many companies, indeed it's probably the accepted norm. That's bad! The Product Owner should be a full-time member of the team and be colocated with the team. If he's not then, in my opinion, the team's agility is compromised . The team cannot possibly achieve all that they are capable of achieving on the project. Time-boxing interaction between the team and the Product Owner constrains collaboration with the business. In my mind, collaboration is not something that you turn on and off depending on the time of day. It's a hive of conversation and activity that permeates the environment generating hustle . If you want to achieve hyper-productivity, one of the things you need to be able to do is talk with the Product Owner, as and when you need to, and to demonstrate vertical slices of a user story many times a day to get feedback. If the project is vital to the business, then the company can always find a way to provide a full-time and colocated Product Owner. If they say they can't, it really means they won't. Quite simply, they're not prepared to do what is necessary to achieve it, and frankly, if they're not going to take the project seriously why should you? Usually, the obstacle relates to a silo'ed organisation where departments are arranged by role rather than product stream. Hardly an insurmountable obstacle ... really.

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:

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: