Agile Coaching

Agile Coaches Dojo Experiments

Many people are now moving into agile coach roles and looking for ways to improve their skills.  In response to this demand, I've developed an Agile Coaching Skills workshop aimed at practicing agile coaches, to compliment my "Agile Coaching" book. If you're interested, the next public workshops are in London on September 15th and Belgium on 17th.

Training can give us a boost but there are still gaps to be filled as we grow into a new role. We need a way for agile coaches to support their ongoing learning without relying on trainers (who are few and far between). Agile Coach Camps and Gatherings provide another great opportunity for agile coaches to get together on a weekend to explore ways to improve their practice and network with other agile coaches but these events tend to be months apart.

Over the years, I've got a lot of help from London's eXtreme Tuesday Club  so I know that there's great value in talking through the problems I face as a coach with other coaches more frequently. However, getting together for an evening pub chat is often a bit hit and miss. We need to create a safe place to practice coaching that exposes budding coaches to different coaching styles.

So I've been experimenting with a new format that can be used by groups of agile coaches to support learning from their peers. It's inspired by the popular Coding Dojo format used by coders.

What's a Coding Dojo?

A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in deliberate practice in order to improve their skills, by coding in front of others. You can find out lots more at, http://codingdojo.org/

There are coding dojos run all around the world rather like local user groups. The coding dojo format has also been adopted within companies for groups of interested developers to learn together.

I've seen coding dojos particularly useful where the team is not using Java or C# and can't get off-the-shelf training in agile practices like Test-Driven Development and Refactoring.

How might this translate to an Agile Coaches Dojo?

Agile coaches work with people rather than computers. So unlike a coding dojo, we don't need to setup laptop computers or a projector to run an agile coaches dojo. A coding dojo simply needs a circle of chairs for the participants.

I tried out my first Agile Coaches Dojo at Agile Open Holland - here's a photo of one of the groups so you can see the setup we used. Basically, splitting the group into circles of 4-6 people.

The other big difference is that coding dojos require participants to prepare for a "kata" on a programming challenge. Here's an example: Write a program that solves word chain puzzles (cat -> cot -> dot -> dog). You can find more example kata at pragmatic Dave Thomas's Code Kata and the Kata Catalogue maintained by Emily Bache.

Coding dojos focus on the pattern of choreographed steps you take towards creating an elegant solution. Coaching dojos would focus on the same thing. The "how" aspects of what we do as coaches, such as what questions we ask and how we work with the person to help them solve the problem.

What would a kata look like for an agile coach? Well, part of the art of agile coaching is to explore a problem domain with a person (rather than a computer). I could probably create a catalog of canned challenges based on my own experience that might be used as coaching katas. Where I would struggle is how to share enough context for a coach to work on those challenges. So in the Agile Coaches Dojos I've run, we have based the coaching kata on real challenges that the participants had experienced. This enables us to explore live situations with the person who needs coaching help. Here's an example of a challenge faced by an agile coach in her own words.

For Agile2010 conference, I added a demo round where I presented a challenge and two experienced coaches took turns to coach me towards finding a solution. Thanks to David Hussman and Dave Rooney for helping me out with this. 

Although I've seen a number of conference sessions for agile coaches based on triads of coach/coachee/observer. I deliberately wanted to break out of this grouping so that people in the circle could see different coaching styles demonstrated (as in a coding dojo). I also prefer to call the person who presents a coaching challenge a Seeker rather than coachee. There's something about the word coachee that bothers me, seems to me like a passive recipient of coaching rather than an active player in the situation. You can download my Agile 2010 slides for some more detailed instructions on the timings we used.

The Agile2010 session got very positive feedback and lots of ideas on how to improve the format. More time would have allowed us to try multiple rounds and also to rotate roles. Some structured sheets for things that observers could look for might also be useful.

Some of my favorite comments from the feedback forms:

• "I was a guinea pig and I liked it."
• "It gave me very concrete ideas for organizing similar dojos in my area. I want to do this more!"
• "excellent session I want to bring it back home."
• "You did teach people to listen. Thanks for that."

Closing Thoughts

My only worry about the idea of an Agile Coaches Dojo is that using Japanese nomenclature will obfuscate the intent of the agile coaches dojo, which is: to create a safe place for agile coaches to practice and be exposed to different coaching styles.

I want to encourage people to experiment with the format (like programmers have done with coding dojos) and so I will be interested in hearing what's worked for you. So please post comments about that, when you've tried an Agile Coaches Dojo in your area.

Tips on organizing an Agile Open Space

The Open Volcano event was put together in less than 48 hours, when several agile luminaries found themselves stranded in the UK due to volcanic ash induced flight cancellations. Attendees were impressed by how well it turned out. Open Volcano isn't unique, Agile Open Space events are springing up all over the place.

They're often low-budget events centered on a specific agile theme, such as:

• CITCON is about continuous integration and testing,
• Agile Coach Camp / Gathering explores coaching agile teams,
• SDTconf delves into simple design and test.

You see Open Space Technology is the perfect match for Agile values. Participants work together to create their own conference schedule just-in-time during the event and set up a great environment for peer-learning. We pay attention to feedback and reflections from participants and adapt the schedule as we go.

I love the buzz and energy at these events as people move like bumblebees from one conversation to another. We start with the warning "Be prepared to be surprised!" and by the end of the day people often are pleasantly surprised how well Open Space works.

So here are some useful tips for when you organize an Agile Open Space event. Some tips I jotted down at Agile Central Europe conference in an open space session convened by Pierluigi Pugliese and others are based on my experience of organizing Retrospective Facilitators Gathering and Agile Coaches Gathering plus facilitating Open Space at many agile conferences such as XPDay, Scrum Gathering, etc.

Start by finding a suitable venue. You need one large room with sufficient space for all participants to stand in a circle with some break out rooms for sessions. Check whether you can stick paper on the walls. You don't need a projector in every room but you will need a lot of flipcharts. Natural light is important and it's even better if there's a garden that you can spill out into. We had memorable sessions at Agile Coaches Gathering out on the lawn at Bletchley Park and at XP2009 we even had some open space sessions by the pool and on the beach!

For an energizing open space, you need enthusiastic participants. However, if entry is free or cheap then people often sign up to reserve a space and plan to decide later whether they will actually attend. The organizers of Agile Coach Camp ask each person to sign-up on a wiki and write a position statement. This statement is a small public commitment showing who plans attend which also helps others get a view of who will be there and their different motivations---especially useful when there's no program of topics to be covered available in advance. You can also create a Topic Incubator wiki page for people toss around ideas for sessions. These topics don't get pre-allocated into the schedule, they're simply there to get the conversation started.

Your next challenge will be putting a budget together so you don't lose money in organizing the event. List all your costs: venue, stationery, food/drink, etc. Offset those with a pessimistic prediction of revenue from registration plus sponsorship. Sponsors come in all shapes and sizes; some are local companies looking to recruit agile developers, others are tool vendors, and you can also get sponsorship from agile community groups like Agile Alliance, Scrum Alliance, and tie-up with your local user group.

If you can avoid charging people to attend then you don't have to worry about bank accounts and setting up a non-profit organization. Many open space events split bills and arrange for their sponsors to pay direct to the venue so as organizers they don't need to handle any money!

Now all that remains is to advertize your event. Social networking tools like Twitter and Facebook can be very effective. News of Open Volcano flashed around the twitterverse and was sold out in less than 48 hours. For events with a longer lead time, keep a waiting list because people often drop out and you need a buffer to fill any vacancies that open up.

Finally, do you need an Open Space facilitator? An experienced person can help create a focus and make it easy for participants to propose sessions. However, I'd say for a community based event, you will probably find someone will do this in return for free registration. If you can't find someone then Harrison Owen's book 'Open Space Technology: A User's Guide' explains what you need to do in plain language. You only need basic materials like sticky notes, markers, and tape. Here's a snap from Open Volcano that shows our schedule drawn out on a white board and populated with super-sticky notes.

Do you have some tips to share about how to organize a successful Agile Open Space? Please add them as comments on this post.

Interview on Agile Coaching at QCon London 2010

Here's a short interview I gave to Craig Smith from O'Reilly at QCon 2010 in London. I guess you can tell that this is completely ad lib :-)

Weird to see yourself captured on film. Only a 4 minute clip. Check out a few agile coaching nuggets wrapped with a smattering of waffle. Let me know what you think!

Is Working Outside-In Always Better?

On Sunday, I went to GOOS Gaggle, a micro-conference on the development ethos described in  "Growing Object-Oriented Software Guided by Tests", the new book written by XP stalwarts, Steve Freeman and Nat Pryce.

After the main presentations, we moved into Open Space format. I joined a conversation with John Daniels and Willem van den Ende about "Why Start with End-to-End Tests?". Although we agree whole-heartedly with this, John was interested to explore whether this approach is always a good idea? You can read John's write-up of our conversation on his blog.

John starts by writing this up on the board.

When you start solving a problem from the outside, you ensure that inner workings connect to the real world setting. You start to grapple with all the interfaces to the system from user interface to the back end activities of logging and persistence. An excellent way to flush out any issues that might catch us out and require rework later on.

 
We wonder if the reason working outside-in and creating end-to-end tests is the simplest way to ensure we tackle risks early. John suggests that the biggest risk on some projects could be in the inner logic, for instance if the project was based on running complex calculations. Maybe there are situations where an outside-in approach may not be the best one to take?

Then I rack my brain trying to remember past projects where we didn't start end-to-end. What were the barriers that stopped us doing this?

The first example I remember was back in 1994 when I was working on a broadband switch demonstrator. My company was providing the call-control component but we were working in a consortium where other companies were providing other components that we would interface to, such as a set-top box, etc. Message protocols were not agreed and the hardware was work-in-progress but we had a hard deadline to demonstrate the kit at an industry expo. We did the only thing we could to make headway. We made-up a reasonable message protocol and then worked against software stubs which piped in messages in our imagined protocol. When the real interfaces were revealed, we mapped them into our own internal protocol, on the way in and out. This worked really well for us. We made the trade show deadline. Another example is more recent. A team I am coaching are building on some content-management infrastructure being developed by another department. It's not ready and they've been trying to work out whether to: wait, work on other features, or build their own solution using existing infrastructure.

Realistically, sometimes you need to make a start without having full end-to-end picture.

Our worry is that sometimes teams may prefer the "path of least resistance" because it's easy or they're naive about integration.

However, we ought not to forget that sometimes the biggest risk is organizational politics. It can be important to demonstrate progress to get buy-in from key stakeholders. Scrum can be perfect for mitigating such risks. We work on tangible product backlog items that we can demonstrate every few weeks. This builds trust in the team's ability to deliver on their commitments.

Willem adds that it can be hard for a team to justify "technical" product backlog items that mitigate risk over juicy features with obvious business-value. The team can attempt to make the value of such technical items more obvious by linking them to the money lost in downtime when a site crashes or security is breached.

Another common approach is to pair a Business Product Owner with a Technical Product Owner for projects where there are lots of infrastructure considerations. John pointed out that there's likely to be a tension between long-term technology decisions and short-term project goals. This is where it can help to have a project manager facilitate decision making. Thus, you need a three-way balance (as in this sketch) rather than (as we see too often) the Scrum team kowtowing to Product Owner without speaking up on technical risks.

Perhaps one of the main values of the GOOS approach and working from outside-in guided by tests is that we are able to flush issues out early rather than attempting to anticipate them. Thus we avoid awkward conversations with a Product Owner about potential risks because the issues stare us in the face having driven them out with end-to-end tests.

Whistle-stop tour of Agile events

My next few weeks are pretty packed with agile events!

This Tuesday evening, I'll be at the London Scrum User Group giving a book reading from my Agile Coaching book. Roman Pichler will also be reading from his new book "Agile Product Management with Scrum".

On Wednesday, I'm off on the Eurostar to Agile Acceptance Testing Days in Belgium where I'll be giving a talk on "Coaching Teams over Acceptance Testing Hurdles". I'd be interested to hear any stories that you have on this topic, if you've got time to add as a comment to this blog...

I'll be back in London on 30 March, to give an "In-the-brain" session at Skills Matter on how to Improve Collaboration, Build Trust which will be an opportunity to follow up on the XPDay workshop that I ran with Sallyann Freudenberg.

 
After Easter, I'm off to Krakow for Agile Central Europe, a new conference where I'll be giving a keynote on "Retrospectives" and facilitating the OpenSpace.

Then I get to the celestial spires of Oxford to run an interactive session on "Understanding User Stories" at ACCU conference. 

Following that I'm looking forward to reflections in Tisvilde Hoejskole, Denmark at the Retrospective Facilitators Gathering, five days Open Space on retrospective facilitation :-)

Finally, April ends on a high, straight after my "Agile Coaching Skills" workshop at Skills Matter in London, I'm off to Germany for Agile Coach Camp 

Hope my family still recognizes me when I get home!

Distributed Agile in a Virtual World

The most thought-provoking session, I attended at Agile2009 was on the Distributed Agile stage entitled "Using Virtual Worlds for Distributed Agile".

Now, I'm not normally a fan of distributed working because communication between team members deteriorates with distance. Alistair Cockburn came up with the neat metaphor of erg-seconds as a way of captures the cost in both labor and time to get a question answered. These erg-seconds (and argh-minutes) are often a hidden cost when a distributed team attempts to apply Agile. However, sometimes you just can't avoid distributed working and I've certainly done my share of skype calls. In fact, when Liz and I wrote our book on "Agile Coaching" months would go by where we didn't meet and instead collaborated via Google Docs and Skype.

Most distributed teams need to brush up on their facilitation skills to make meetings via teleconference bearable (see earlier post). However, at State Farm Insurance, teams have been experimenting with virtual worlds. At Agile2009, Keith Voos and Ami Hileman demonstrated a virtual world used by an agile team to collaborate with team members in multiple locations. I was impressed by their findings; for example, conversations in the virtual world were better quality than a conference call and internet access was lower bandwidth than for webcams.

Keith and Ami showed us a virtual team room that a team has been using for activities like:

• Creating stories
• Estimating tasks
• Radiating information
• Tracking work
• Daily Scrum meetings
• Retrospectives

The space looks very much like a physical team room with colored sticky notes posted up to create a virtual story tracking wall. The developers have also used the virtual world for remote pair programming. There are typical team artifacts: a whiteboard, a burn-chart, a lava lamp showing build status, a calendar, a clock, even some Dilbert cartoons! I've pasted some photos below.

It hasn't been all roses, they have had experience of accidentally deleting walls and also removing avatar clothing. And, of course, virtual worlds don't solve timezone differences. However, the team finds this way of working is fun. On Fridays afternoons, they also play a bubble-shooting game in the virtual world which has helped team building.

I was impressed by the amazing potential of virtual worlds for distributed agile teams, so many people who work in software industry are gamers, it seems blindingly obvious that this is the way ahead for more teams. The tools shown were Qwaq and SecondLife but there are many others out there. And who knows, you may find the cost of these tools cancels out some of those dreaded erg-seconds.