The biggest news from Agile 2009 this year is that the PMI has launched the PMI Agile Community of Practice. As there are many historical and cultural differences between the two groups, the shared hope is that by communicating and sharing understanding there are opportunities for everyone to succeed. Not everyone agrees. Check out this InfoQ article for some other points of view.
I have some really cool mind maps and visual notes from Agile 2009. These will take a while to get posted since I need to scan them when I’m back home (Still in Chicago to attend Lean training with Mary P) and then some time to upload and comment. There’s an RSS feed for this blog, so stay tuned.
After a couple of Agile 2009 sessions on coaching I realized I was even more confused than ever about how to think about my work as an Agile Coach. Arto Eskelinen and I decided to run an OpenJam to clarify this. Thanks to: Lyssa Adkins, Tobias Mayer, Dave Nicolette, Rachel Davies, Tim McCoy and David Fox. (Sorry if I missed anyone.)
After brainstorming ideas, we were able to cluster them into three layers to reflect different logical levels. Let’s go through them in turn.
Goal of Coaching
The first level is about what we hope accomplish by working with a client. The primary purpose is to help the client to self-actualize – to move them forward on their journey towards reaching their potential.
Note that an engagement will involve three types of clients:
(In this blog, I’ll talk generically about clients – it could be any of the three types.)
That’s a lot to do, so it’s important to choose…
To be effective, it helps to understand where the client is in regard to a particular skill. One model is Shu (Beginner) – Ha (Practicing) – Ri (Expert) that Allistair Cockburn talked about at the keynote. Another variant of this is the Dreyfus Model of Skill Acquisition: Novice, Advanced Beginner, Competent, Proficient, and Expert. The type of intervention we choose as a coach depends on the skill level of the client: a beginner may simply be taught, while a guiding and clarifying is needed when skill is higher.
We talked about understanding your client’s needs at any point in time. The traditional approach from consulting is to assess the situation and make a recommendation. The assessment could be a formal one or based on ongoing tacit knowledge. Related to this is the goal of a healthy client (team). As an Agile coach, one model is to diagnose problems and provide prescriptions/guidance. This seems like common sense but kept coming up as a critical success factor.
Roles played by coaches
The above image indicates some of the roles that were identified (probably a bunch missing). Here’s what came up:
- Change Agent
- Story Teller
One interesting comment was that an Agile coach has a specific agenda – adoption of Agile – that was in conflict with pure coaching. Now that I have benefit of a few days to reflect, I this does not seem to be a conflict. As an Agile Coach, if I don’t think a client will benefit from Agile, I won’t take them there.
Steward of the Process
Another role that I would like to call out separately is Steward of the Process. I think it is probably true in many cases, but I find this a little alarming since as a coach I would like to leave one day and have my client succeed without me. Perhaps as a transition plan, we need to find a new steward and then coach them to be successful in that role.
Do no harm
One final point to mention is do no harm! We are there to make clients (individuals, teams, organization) successful, not to inflict Agile process and practices indiscriminately. Even if we know something is really good, it might not be the right thing for this client at this point in time.
A couple of weeks ago, I needed to run a workshop for some people new to Agile. My initial plan was to use the XPGame by Vera Peeters and Pascal Van Cauwenberghe. It’s really great, but it’s XP (not that there’s anything wrong with that). From my perspective the process part of XP is almost indistinguishable from Scrum (except that Scrum provides more safety by making some things explicit). I thought I would be OK to use with my client who is transitioning to Scrum (+XP).
Initially I thought it would be healthy to present the XP-perspective since it is not that different. The part where I got really stuck was using the term developers for the team. It didn’t feel quite right so some reflection, I decided to modify the XPGame to become a Scrum simulation. The rest of this blog how to do it.
I got really great feedback from the folks who attended and someone from Agile 2009 was looking for this so I thought I had better post my notes.
2 Hour Agile Introduction and Simulation
The audience was people who were new to Agile. They heard about Scrum from other teams and wanted to learn more.
First 30 minutes – slide show introduction to Agile (IID & Waterfall History, Game of communication and cooperation, Agile Manifesto, Who uses Scrum and what for, 1 slide each on Scrum, XP Engineering practices, Crystal Clear and Lean.
Next 90 minutes – The simulation described below. Note: we only had time for 2 (not all 3) iterations.
Pre-production: Learn the XPGame
The first thing to do is read through the manual and the rest of the goodies in the XPGame. It is chock-full of great stuff. I am not going to replicate the XPGame for you – just go download it (link above) and go.
The main part that we will re-use from the XPGame are the stories. These are fun things like blowing up balloons or building a card house. People who walked by the meeting room thought we were having a party! As well, you’ll need to fill a bag with all the supplies. Oh one more thing – maybe Canadians aren’t as well trained as Belgians, but one problem I ran into was how to make hats and boats. There are lots of online instructions. Here are the ones I used for hats and boats.
Use 1 Slide for the whole game
I ran the who game off the one slide below.
The ovals represent activities that take place. The artifacts are as indicated. The arrows show the flow of activities and how artifacts are transformed.
The location of the Product owner (purple) and team members (blue) indicate who is leading and who else is involved. There are also stakeholders (green).
(You are welcome to use this slide under Creative Commons 2.0.)
Story Writing Workshop
In this step, I hand out the stories for the iteration to the PO’s (Product Owners).
This works pretty much as described in the XPGame. One difference with Scrum is that although the team owns the estimates, the PO participates as well since she usually has relevant information.
This is done in a commitment-driven fashion with the team accepting one story at a time until the team think it cannot take on more work. As stories are selected, they are posted on the ScrumBoard.
Another change from the XPGame is to use a ScrumBoard to track what stories are planned, in-progress and ready for acceptance. See photo on the left. This helps coordinate the team and allows non-team members to see what is going as well
I used the really large 3M posters although flip chart paper or just tape on a wall would work too.
One more thing: you will need to get 3M PostIt Restickable Glue Sticks so the cards can be moved around.
The XPGames mandates that only one story be worked on at a time. In my game, I let the teams decide how they wanted to work. Self-organization?
Timers. The XPGames says to use a 3 minute sand clock (I couldn’t find any) and pause them while answering questions and acceptance testing. This would fine if I had just one team, but I had 3 team! The workaround was to run a large display timer on the overhead projector. I used XNote Stopwatch and set it to 5 Minutes. That worked OK. I may try 4 minutes next time…
Sprint Review Meeting
This is where I (as head PO) accept or reject stories based on acceptance criteria.
I talk to the diagram and let them know what usually happens before running the Iteration Debrief questions.
Learn More at our Certified Agile Leadership Training.
Check the Calendar Here:
A bunch of the folks I am working with now have started to use the Pomodoro Technique. This is really cool and a great way to boost productivity.
One of the challenges is people interrupting because they don’t know someone’s in a Pomodoro. So, one compensation (not a solution, just a mitigating technique) is to use … Desk Flags.
- Flag up = “I’m concentrating – do not disturb.”
- Flag down = “It’s cool to talk to me.”
Here you can see two people working, the closer person has a flag up.
The flags were ordered from DeskFlags.com and they sell this cool 360 degree “click-it” (red and white object in the photos below) that allows one to easily swivel the flags around.
This is how they are mounted.
As I mentioned before, this is a compensation for when people are working solo. An even better compensation is pairing, but that another story…