Agile Coaching

Introducing Agile Techniques to Teams Outside Software Development

Recently I've been helping teams outside Development apply some basic Agile practices. Our company was founded using XP at the core of our approach to software development. We've grown along with the success of our products and now have several departments with day-to-day work that does not involve the Development team (such as Finance, Infrastructure, and "People & Places" who combine HR and facilities management) interested in managing their work along similar lines.

Rather than blasting these teams with Agile theory and principles, we're building things up slowly. We start with a simple sketch about how to make the work for the week visible on the wall then put it together using super-sticky notes - see the photo from our Infra team based. Columns can be added as needed and, when the system seems to be working, lines can be added with tape. Our People & Places team brought in a spirit level and some flowery scrapbooking tape for to make their wall beautiful.

 

Around the board, we run a simple meeting cycle: surfacing and prioritising work for the week ahead, daily standups and monthly retrospectives. People on these teams are positive about the new approach because it helps them to know what's going on around them and have the benefit of advice from team members. They're also enjoying spending more time together as a team and getting a buzz from seeing how much work has been Done. Our People & Places team even have a large photo album where they file all their Done tickets so they'll be able to look back later.

Challenges that come up are pretty typical things we see in software development teams, like long standups and large tasks that don't move. We don't currently estimate the work or apply work-in-progress limits although we've discussed whether this might be worth experimenting with. For now we're limited by wall space and when columns get too full we can see we're being a little optimistic -- taking on too much work or have a lot depending on external suppliers.

Based on this experience I convened an Open Jam discussion at Agile2012 for people who were also interested in applying Agile techniques with non-software teams at Agile. You can see the original flipchart notes here.  I've reworded them a little to help the points discussed clearer.

What's different outside software development?

• Not having a shared goal (on the org chart but not sharing work as a team)
• IT based examples may not help communicate ideas to non-software people
• Work may be very fluid or constrained by lead times and dependencies on other groups
• Team members may be used to being told what to do
• Team members may be uncomfortable with increased visibility of their work
• Team may have more varied experience levels whereas in software development most are engineering graduates
• Individuals may not be interested in team goals if they have a strong focus on their own objectives

What techniques are not specific to sw dev that you can try anywhere?

• Visible work "Kanban"
• Standup meetings
• Setting priorities as a team
• Limiting work-in-progress
• Retrospectives
• Product Owner role (responsible for priorities)
• Coach role (helping team reflect and improve)
• Reviews / Showcases of work done
• Timeboxing / Pomodoros (http://www.pomodorotechnique.com/)
• Pairing
• Test driving without automation
• Visible outcomes - iterating over visible product
• User stories: Who? What? Why?
• Frequent user testing
• Interactive facilitated workshops
• Shorter more focussed meetings with only relevant people
• Balancing relevance against exclusion
• Focus on throughput over efficiency

Getting the conversation started:

• Explaining the value over beer or coffee
• Introducing facilitation as a way to make meetings more fun
• Executive evangelists
• Arranging a tour of software development teams using Agile
• Finding one open and curious person
• Organising a team reliance - involving all hands as supporters
• Making an Agile coach available to teams outside Development
• Crafting an interesting elevator pitch
• Create interest with cool looking stuff

Poll of areas where people at this Open Jam were applying Agile outside software:

• Publishing school text books
• Finance
• Exec team
• National sales
• HR
• Marketing
• Infrastructure
• Supply chain optimisation
• Political programs
• Volunteers at conferences and festivals
• Academic researchers
• Working with children (at school and at home)

If you came to this Agile2012 Open Jam session, please let me know if I've missed anything important from this write-up. It would also be great to hear from anyone who has tried applying Agile techniques outside software, what challenges did you encounter and how did you overcome them?

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.