Agile Games

One of the most memorable and rewarding sessions I attended on agile games was not on any stage however, but in an Open Space on the 1st floor of the conference center.

It was entitled Where Are Your Keys?

Diana Larsen, who had successfully captured my interested on the subject by writing and tweeting about it earlier this year, facilitated the WAYK Open Space session. (you can see more on WAYK at XP2010)

I found myself sitting in a circle looking down on a collection of objects (red pen, black pen, rock, stick & dollar) with other industry experts such as Michele Sliger and Linda Rising. We quickly formed 3 concentric circles. The 1st circle was the Inner Circle, the 2nd circle the Lunatic Fringe and the 3rd circle the Meadow.

At a basic level, the Inner Circle started off with very simple sign language about the object that lay in front of us. The outer circles mimicked their actions to help support them. In about an hour, we went from not knowing any sign language to speaking in past, present and possessive tense. By myself, it is very unlikely I would have ever made such a rapid progression in this short amount of time.

Part of the reason this was possible is that we had a non-threatening way to deal with mistakes, as we’d just throw up our hands and say “How Fascinating!” when people floundered. It created a safe environment for collaboration and learning.

While this session was not for everyone, I found it rather enlightening. I’m not certain that I’d recommend the game for all agile teams, but for groups of agile coaches & facilitators it works rather well. WAYK gave me a refreshing perspective on just how effective group learning in a safe environment can be, and is a gentle reminder about how we cannot get too caught up in our mistakes.

I placed the emphasis this problem recently during my talk on distributed agile. My audience received, perhaps unexpectedly, a heavy dose of organizational culture from me instead of “here’s the 1000 different tools you can use” speech.

My message was simple, team members are not resources or metrics, and we should not treat them as such.

I felt the need to build upon that talk. As a result, here are my 7 tips for a sustainable and healthy distributed team experience:

1. Use Video Chat - It is much easier to create a personal connection when you can see one another. Facilitation relies a great deal on body language, and with today’s cheap video technology there aren’t many excuses on why you cannot use it. Involve stakeholders so they can put faces to their team.

2. Establish Trust With Retrospectives – These are a great way to lay a foundation of trust with your distributed team. It can be difficult to pull everyone together as a cohesive team image, but these will help tremendously if held on a regular basis. You can mix them up and have fun with them by using a product like Innovation Games.

3. Refrain from Jokes – Snarky comments and jokes, while funny you to, do not translate well to other cultures. It is best to keep these to yourself when communicating with your distributed team.

4. Organize Team Outings – It can be difficult to secure enough money to fly everyone in for a get together, so instead try to organize events close to your team members. For example schedule a bowling night for each location.

5. Split Up Lengthy Meetings – Distributed teams often have smaller windows of overlap with regards to office hours. Be aware of this and split the day long planning sessions into multiple parts over a few days. Yes it’ll slow things down a bit, but you won’t be keeping team members from their families.

6. Try Virtual Pairing - Team members often produce great software when they physically pair on a computer. Just because you are in different locations doesn’t mean you cannot pair over the web. Skeptical? Go read up on the efforts over at Industrial Logic.

7. Avoid Metric Obsession- Distributed teams risk being perceived as a faceless velocity viewed through agile lifecycle management software. Continue to stress the importance of the people behind the metrics to those who miss out on the team interactions.

Unfortunately as more companies offshore/nearshore software development, it is an emerging trend to treat people in a very inhumane manner. We need to be aware of the people behind the screens, and hopefully by using these techniques we will help humanize the distributed team experience.

I would take that a step further and say that the ScrumMaster is the mirror for the team.

A team often unintentionally falls back into situations in which they’ve previously committed to improving.

For example, let’s say that in the last iteration retrospective the team decided that they need to expand the ownership of each story. The last iteration was a success, yet it seemed as though they were not collaborating effectively. Each user story had one developer doing most, if not all of the assigned tasks.

As a ScrumMaster, you also notice that early on in this iteration there continues to be very little or no overlap in story and task ownership.

It is your duty to speak up (in a non-critical way) and remind the team that they’ve committed to improving this aspect of their software development process. Take a minute and ask them if they’d like to switch stories for the day, pair on tasks, or otherwise find a way to solve this recurring dilemma. In a fashion, you are reflecting back to them their current behavior so they can reason out how to improve.

This is the ScrumMaster essentially acting as a mirror for the team.

Now take the ScrumMaster out of the room, and spread the team around the globe.

Instead of addressing this situation as it happens, a Distributed ScrumMaster would need to look for specific behavior on a virtual scrum board or pick up on it over video / phone chat during a Daily Stand Up. Depending on your unique Distributed Scrum setup, this would most likely not be a quick feedback loop. A Distributed Scrum team with little or no overlapping hours would put the ScrumMaster in a situation where the events may have happened a day ago. In my opinion this is one of the reasons Distributed Scrum teams inspect and adapt more slowly than Collocated Scrum teams.

I’ve found that it can be difficult enough to serve as a mirror for the team when you are literally in the same room. Doing this on a distributed scale requires a ScrumMaster with keen observation skills, patience, and a belief in magic.

So where do you begin?

Step 1: Soliciting Feedback

An empty whiteboard should haunt your dreams!

If you are allowing stakeholders, internal or external, to leave the room without providing feedback then you are neglecting a very important aspect to your software development cycle.

Issues are either being left unspoken or your customers are not engaged at the level they need to be for your team to succeed.

• Simply ask them.
• Avoid analysis paralysis.
• If they have scheduling conflicts send them an interactive demo link.

Tip: Be creative in soliciting feedback and do not take stakeholder avoidance lying down.

Step 2: Clarifying the Confusion

Talk about each feedback item with the entire team in the room and try to reach a level of understanding. Often people have difficulty articulating what they mean. and you want to avoid everyone nodding in lukewarm agreement with one person is thinking square, the next circle, and everyone else triangle.

• I love it!
• I hate it!
• What ever happened to _insert obscure functionality request here_

I suggest using 5 Whys to help clarify each statement while clicking through the demo:

“I love it!”
“Why do you love it?”
“Seems so much easier to read!”
“Why is it easier to read?”
“Well these fonts across this menu..”

Clarifying the feedback, regardless of whether or not you agree with their opinions, will help in turning these into actionable items.

Tip: Feedback reflects more about the person and less about your demo or product. Try to refrain from knee jerk reactions during the conversation.

Step 3: Deciding on Go / No-Go for Release

Remember that the goal is having a releasable product at the end of the iteration. It isn’t mandatory that you release, but the conclusion of the demo should provide the team with clear guidance on next steps. If you can identify a handful of small items that are blocking release, I suggest reaching consensus on these and swarming on them as a team.

You may want to schedule your demos in such a way that you have time to anticipate small changes before you release to production.

Tip: I’ve worked with Scrum teams that held a demo every week, and released every two weeks. You are not restricted to the end of your iteration for demos.

Step 4: Seeding the Backlog

Take the time to document every piece of feedback, not just the items in which you are addressing before you release to production.

Convert them into the applicable artifacts such as:

• Stories
• Defects
• Tasks

Tip: Nothing frustrates a team more than a bunch of undocumented feedback that crops up after every iteration.

Good luck and remember, negative feedback is better than no feedback!

For those to lazy to read the previous article, the ones I listed were:

Michele Sliger
Esther Derby
Jeff Sutherland
Ron Jeffries
Kent Beck
Ward Cunningham
Mike Cottmeyer
Scrum Alliance
Martin Fowler
David Alfaro

Twitter was somewhat less popular then, but I found that the combination of the pay it forward vibe of the agile community and the open medium of Twitter allowed you to forge online relationships prior to meeting people in person.

Want to know what’s going on at Google with Jeff Sutherland, well you can just ask him.

Would you like to know what Esther Derby thinks of your retrospective ideas?

Not to mention the countless other very cool experiences I’ve had such as job interviews for agile coaching positions, conference stage producer opportunities, etc.

So I’ve decided to revisit this post, and supplement your endless thirst for knowledge with 10 more agile gurus you should follow on Twitter.

1. Eric Ries

2. Jesse Fewell

3. Brian Marick

4. Tobias Mayer

5. Chris Sterling

6. Rachel Davies

7. Lisa Crispin

8. Diana Larsen

9. Cory Foy

10. Alan Shalloway

Take the chicken & pig story used in many introductory paragraphs to Scrum:

A chicken and a pig are together when the chicken says, “Let’s start a restaurant!”.
The pig thinks it over and says, “What would we call this restaurant?”
The chicken says, “Ham n’ Eggs!”
The pig says, “No thanks, I’d be committed, but you’d only be involved!”

I shudder to think of the newly trained ScrumMasters or Product Owners that return from their courses to label their fellow coworkers as chickens or pigs. How is that in any way going to help foster adoption? You can try to dismiss the scenario, and I’ve listened to CST’s reason through how their trainees could never be that dense. I’ve heard the argument “Well we only use it as an introduction…” however I’m growing tired of us introducing the framework using a joke.

It is as if we’ve taken a 4 line parody and turned it into a world view. I honestly cannot understand why it has stuck with us for so long and it is time to let it go, as the labels do nothing to help promote our cause.

Another Scrum phrase I still see thrown about in a derogatory manner is the infamous Single Wringable Neck, or One Throat to Choke.

Being a Product Owner is a tough job, but as Mike Cohn wrote last December the Product Owners are not solely responsible for the success of a project.

Scrum teams succeed or fail as a, well, a team.

If the Product Owner is confused about the role or not living up to expectations, it is the ScrumMaster who should be helping them along the way. If the ScrumMaster is failing at coaching up the Product Owner on the framework, then wouldn’t the ScrumMaster be to blame? But wait, since the team has appointed the ScrumMaster, would they not have failed by choosing one who is incompetent?

We’ll just run in circles pointing fingers because there is no easy answer, and using the Product Owner as the scape goat does nothing to help resolve the situation.

I’m as guilty as any at poking fun at Scrum terminology, there comes a time when we need to grow up and recognize that it is no longer where we need to be as a community. It is becoming a hindrance to adoption as the Scrum framework rises in popularity.

By striking these terms and phrases from our professional vocabulary, it is a small step towards breaking down adoption barriers and promoting Scrum as a positive force in the community.

As a virtual story wall for distributed teams.

It only takes a Google Account, a few minutes of your spare time, and most of all it’s free.

Create a Google Drawing

Draw a large rectangle & create columns with the line tool

Give each column a name using the text tool

Find an image of a post-it (change the colors in an image editor if needed)

Insert the images into the Google Drawing

Create text box overlays on the post-its using the text tool

Copy & paste them onto the story board as needed. (keep the originals in the gutter)

Give it a name & share it with your distributed team

I shared the Virtual Story Wall used in this tutorial if you wish to get a better idea of the scale. It is only a guide, and you can customize yours with different columns and images such as index cards or push-pins. If you’d like to extend the use of Google Docs for your team, my next post in this series will include a sample Burn Down spreadsheet template.

Even more surprising, is just how quickly the ScrumMaster salaries have increased in such a short amount of time. As you may remember, I performed similar job research in Oct 2009 when the ScrumMaster role pulled in around $88,000 a year.

ScrumMasters now make on average $95,000 a year, which is a $7,000 increase.

On the other hand, Project Manager salaries seem to have become stagnant, showing no visible signs of improvement. Even the ambiguous Agile Project Manager salary seems to have hit a glass ceiling.

I cannot say that I’m completely surprised by this trend as I’ve witnessed first hand the influx of Certified ScrumMasters over these past 6 months. While I don’t have official numbers, I can tell you that I’m bombarded every day by requests for the LinkedIn Certified ScrumMaster Group. This is a group moderated by myself and a few others that requires an active CSM before approval. We even recently made a request to LinkedIn to increase the maximum group size as we’d hit their member limit.

With the ScrumMaster in such high demand, can we expect these salaries to sustain this sort of growth in an economy that may be dipping into yet another recession?

One trait in particular that is extremely counterproductive to the role is passive aggressiveness.

As someone who has been known to be snarky on occasion, I’ve had to practice my facilitation skills over time in a real team setting.

While I do feel as though I have several qualities that make up a good servant leader, I have traits that can make it more challenging as well. This is especially true if I’m simmering under the surface because the team has recently:

• Missed their iteration commitment by a large margin
• Verbally fleeced one another during a daily scrum or retrospective
• Stopped showing up for daily scrums
• Pulled random stories out of the backlog to work on
• Told me I have no idea how to do my job
• Decided they didn’t like Scrum and tried to get me fired
• Performed a myriad of other actions that drive ScrumMasters crazy

Note: most of these will happen to you at some point along the way if you work with enough teams

To address issues such as these you have to take a very zen-like approach to your role, and serve as a mirror for the team without feeding into the negative energy. This requires you to think before you say anything to the team, which takes practice over time.

For example, even short comments such as “Well I guess we won’t make the commitment this time either” off the cuff can seriously undermine your team’s efforts. If they are stressed due to an unforeseen complexity in a story, then you need to simply note that and do your best to help them adapt. It can be addressed in a positive manner at the end of the iteration.

If after a while you feel as though you keep making these comments over and over, then perhaps you should step back and re-evaluate your role. Try to find a local user group to commiserate with, or reach out to an agile coach online. I’ve found this community takes a very collaborative and pay-it-forward approach so don’t go it alone.

Have any of you struggled with suppressing passive aggressive or other counterproductive tendencies while facilitating, and if so where did you turn for help?

It isn’t a question you’d expect to hear from a team adopting work in progress limits and just in time tasking while only committing to small user stories.

One of my favorite aspects of being a ScrumMaster and Agile Coach is witnessing a team evolve by inspecting and adapting over time. Granted it isn’t a ride for the faint of heart, but it can be an extremely fascinating experience. This is especially true when the team feels empowered enough to mold themselves into a highly functioning unit.

From my experience, this becomes most apparent during iteration retrospectives.

Retrospective #39 Notes

• Team decided tasking entire two week iteration in one day was burning them out.
• Unable to focus for long periods of time & felt as though it was delaying coding efforts.
• Tasks became obsolete half way through the iteration because of what we’ve learned by digging into the code.
• Decided to break tasking down into two sessions per iteration.

Retrospective #40 Notes

• Team still feels confined by the 2 tasking sessions.
• Seems as though we’re spending too much time tasking at once & still have obsolete tasks.
• We decided to task in smaller bunches, 2-3 stories at a time as needed throughout the iteration.

Retrospective #41 Notes

• Tasking as we go is working much better, yet it does result in more interruptions.
• Team wants to adopt work in progress limits for stories.
• Limits will help us prioritize, ensure stories are in good shape before moving on.
• We decided to set our work in progress limit to 3 open stories at a time.

Retrospective #42 Notes

• Keeping our WIP of 3 open stories.
• Tasking as we go interruptions are less of an issue now.
• Medium & large stories are killing our flow.
• Only commit to small & extra small stories to help with flow.
• We decided to decompose anything above a medium down into smaller chunks.

Could you be witnessing a team inspect & adapt itself into Kanban?

Since this team is still running two week iterations, and keeping a good bit of the Scrum ceremony I’m not entirely sure. It seems to be more of a Scrum / Kanban mix for now (Scrumban?), and I don’t see them discarding the rest of the Scrum ceremony anytime soon.

It should continue to be an interesting ride, that is for certain!