Agile Coaching

Summer Events for Agile Coaches

Summer is here at last with blasts of rain and sunshine. Here some upcoming events that might be of interest to you as agile coaches in the UK.

The first one that I'd like to bring to your attention is the Agile Coaches Gathering at historic Bletchley Park. This event is put together by volunteers (yours truly and Manav Mehan). The event starts on Friday with an Open Space gathering to create a lively program of conversations and simulations relevant to agile coaches. In the evening we venture into Bletchley for dinner at the local chinese and indian restaurants and beers in the pub. The sessions run throughout the day on Saturday. The past two years we've had sunny weather and many sessions outside on the lawn. As I write, we already have 40 people registered for the event and just 20 places left, sign up here to get yours.

 
I'm also excited to announce that I'll be running my Agile Coaching Skills training course in London on 25-26th August. This workshop style class has been extremely popular, past attendees include Jon Jagger and John McFadyen. Unlike a Certified Scrum Master class, we assume that you have some agile experience and our focus is on skills that you need to coach agile teams, such as the art of facilitation and System Thinking.

 

 

If those dates don't work for you then why not venture along to eXtreme Tuesday Club? Everyone is welcome just sign up on the wiki no registration required. It's on every Tuesday, just pop in after work on a sunny evening. You'll get a chance to chat to an eclectic mix of agile practitioners and luminaries like Steve Freeman, Liz Keogh, Tom Gilb often come along. Follow @extremetuesday on Twitter for announcements.

If you're not close to London then maybe one of the upcoming regional events might work for you:

• Agile on the Beach on 15-16th September with keynotes: Mary Poppendieck and Kevlin Henney.
• Agile Cambridge on 29-30th September with keynotes: David Anderson and Jurgen Appelo.
• Agile Yorkshire and Agile Scotland also have regular meetings.

Please post a comment if I've missed any crucial summer events. Hope to see you at some of the above!

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!