On May 6^th and 7^th, I attended an Innovations Games^® consultant’s class hosted by Luke Hohmann.  Innovations Games^® are collaborative games designed to help business people develop and prioritize new product ideas.  In the context of Scrum, these games are tools the Product Owner and product designers can use to engage the customers and different business stakeholders in defining the requirements for a product and thinking about product roadmap and multigenerational release plan.  Not a lot is written about the “fuzzy front-end” for Scrum teams and Innovations Games^® fill that significant gap in way that is consistent with the Scrum values and principles.

It was quite instructive to hear about the games and how they work from Luke.  From the different case studies discussed, we really illuminated the dynamics involved with selecting the right game for problem.  In addition, a few of my misunderstandings about the purpose of the games and how they are played from reading the book were cleared up as well.  What I liked most about the class was in addition to talking about the games, we played a lot of them in the course of two days.

1. Remember the Future (played)
2. Prune the Product Tree (played)
3. Speed Boat (played)
4. Product Box (played)
5. Buy a Feature (played)
6. 20-20 Vision (played)
7. Show and Tell (played)
8. The Apprentice
9. Start Your Day
10. Spider Web
11. Me and My Shadow
12. Give Them a Hot Tub

Below are pictures of the Product Box I created for Look Forward Consulting announcing the new service available.  I look forward to using these games more and helping Scrum teams with improving prioritization and collaboration with their customers.

Being a ScrumMaster is much more than just showing up for the Scrum meetings and lobbing in a few facilitation techniques to keep things moving along.  Yet I think many project managers who are new to being ScrumMasters misunderstand what is required of them.  I feel they read about Scrum in one of the many excellent books on the topic and think, “Facilitation…four meetings…lessons learned…planning…task tracking.  OK, that looks easy – I can do that in my sleep.”  All they can see are the transactional aspects of Scrum.  Since that is all what Scrum is to them, they bring the empty project management mindset to the work and the result is a functional Scrum without any purpose, rituals without any meaning.  And this is where I think many project managers turned ScrumMaster stumble with the role.

An excellent ScrumMaster has a real presence with the Team.  To become an excellent ScrumMaster one must go beyond the simple transactional elements of Scrum and focus on the transformative aspects of the work.  As ScrumMaster you need to focus, really focus, on the needs of both the Team and the individuals as you work to improve the environment they work in.  You need to be both physically and emotionally there for them in a profound way.

Scrum’s great promise is that it reconnects people to each other work through empowerment and true collaboration.  As ScrumMaster it is your responsibility to facilitate collaboration, to help people feel comfortable and willing to take both professional and personal risks.  This does not happen in a fifteen minute Daily Scrum, or a two-hour Sprint Planning meeting or during a Sprint Retrospective.  Those rituals have very specific goals and individual coaching is not one of them.  The moments where one-on-one coaching happens and trust is developed are the times when the people are doing the work.  It is those moments when one notices a Team member’s joy, disappointment, frustration, happiness and anxiety.  You catch them being real and experience the moment with them.  This only happens when you share physical proximity, observe and be present when these moments happen.

In Scrum, we strive to give the Team members slack and ask them to limit multitasking to preserve their focus.  We expect the same from the ScrumMaster and that is why I recommend new ScrumMasters only focus on one Team.  If as a ScrumMaster you are lurching from fire-to-fire, meeting-to-meeting, team-to-team you are still operating in the old project management paradigm and it needs to stop.  People on the Teams need your help.  Stop being so busy and focus on what the Team needs for a change.

Passing on some good summer reading.

1. Core of Agile and Scrum – essential principles of Agile and Scrum that transcend the software development.
2. Three Legs to an Agile Transition – George Dinwiddie looks at how teamwork, visible progress and continuous improvement are key to change organizational culture.
3. Why Multiple Product Owners is a Bad Idea – read the article to find out how having multiple people setting priorities short circuits the role.
4. Nobody Can Do Agile – Simon Bennett explains why Agile is about thinking, not doing.
5. Agile Requires Cross-Functional Teams – Johanna Rothman discusses why cross-functional teams are essential for Scrum and other Agile processes.
6. Sir, Please Step Away From the Team – common the changes in management style for managers when Agile teams start in your organization.
7. Story Time! The hidden Scrum meeting – ever wonder when the requirements and the analysis happens on a Scrum Team?
8. How Does a PM and SM Coexisit? – a reader asks Michelle Sliger how the role of the project manager changes with the introduction of ScrumMasters.
9. Truly Agile CMMI – a short blog and video about a company that gets both Agile and CMMI.
10. Millennials and Scrum, Made for Each Other – Lyssa Adkins talks about how the Scrum values and principles align with a new cohort entering  the workforce.

Links to share with your friends and co-workers

1. Is an Agile PMO possible? – Curt Finch talks about the values of both Agile practices, PMI standards and how to marry the two.
2. Self-organization: the secret sauce for improving your Scrum team – In this 90-miute video for Google, Jeff Sutherland talks about the role of self-organization and other advanced Scrum techniques.
3. The Agile Flywheel – a short experience report describing how one company melded Scrum with their mature ITIL processes.
4. Just do it: a quick intro to Agile’s technical practices – a summary of the technical core of Agile software development by Abby Fichtner.
5. I love pair programming – Discussion on the effectiveness and the challenges of pair programming after a five month trial.

Here are some links to the best of the blogs since the beginning of the year.

1. The Role of Leaders on a Self-Organizing Team - Mike Cohn talks about the important role management continues to play on Scrum teams.
2. Agile Scales, Waterfall Doesn’t – or so claims Vasco Duarte during this 48-minute video from the Agile Eastern Europe 2009 Conference.
3. Scrum, But – in this 10-minute video Scrum co-founder, Ken Schwaber, explains the negative impact on your business of “We use Scrum, but…”
4. Management 3.0: The Era of Complexity - Jurgen Appelo describes the new role of social networks as management dives into the 21st century.
5. Faster, Better, Cheaper! TDD wins in a simple experiment – a side-by-side comparison of two software developers working on the same project – one using Test-Driven Development (TDD), the other not; the developer who used TDD increased his productivity by 50%!
6. Agile Game Interview: Simplicity is Hard - Clinton Keith interviews Chris Ulm, CEO of Appy Entertainment, about why Agile is an essential factor in their successful launch of high quality, iPhone games.
7. Embedded Collaboration - Dave Rooney kicks off this post with a classic quote from “The Princess Bride” to explain the real meaning of collaboration.
8. Agile Office Space – the Motley Fool shows off their cool Agile workspace and describes the principles they used to create this space.
9. Wives of Rockstar San Diego Employees Have Collected Themselves – apparently some people are fed-up with yet another death march in the gaming industry and interesting from commentary from Clinton Keith that Scrum is not the solution, but provides visibility and a reality check to wishful thinking.

Last week, I completed the my Agile Team Training class.  I had a really good turnout (~20) and it was a lot of fun!  While reading the class reviews, a common refrains from the participants were they were surprised at how engaged they were in the simulation and how committed they were to the outcomes.  One participant even wrote these kind words:

“I was skeptical that it [SIMSOC] would provide any valuable lessons.  I was pleasantly surprised to observe behavior developed that mirrored my professional experience closely enough to be instructive.  I joined in more fully than I anticipated.”

For those of you that might be curious on what we actually did for the day, here are some photos from the event.

In my experience, having the right venue goes a long way to setting up a good learning experience so I was pleased to have this large space for the class.  This is the great space we had for the event, right on Mission Bay with plenty of natural light, windows looking outside and good food to eat.

During the simulation participants are divided into different regions.  For this game we had three regions: Green, Yellow and Red.  In this photo, the Red Region trying to understand the SIMSOC rules and figure out a game strategy.  The members of this region quickly coalesced around a common goal, but had some initial difficulties convincing others.  Unfortunately, their riot in the first session was unreported by the head of the mass media (MASMED) and did not have the intended effect of getting the rest of society to pay attention to their concerns.

While SIMSOC looks like people are just sitting around in chairs all day, the game is much more dynamic than the photos depict.  This a member from the Yellow Region visiting the Green Region to discuss game strategy. Somewhere around the third session, there was freedom of movement and people began meeting face-to-face to discuss issues and share ideas.  Very soon after that, the Red Region proposed a compelling national program to organize the society around and the game came to close during the sixth session.

Here are some the things the participants learned about teamwork during the class:

“Maintain the big picture to maximize individual contributions.”

“We were all seeking cohesiveness and cooperation.”

“Common goals across teams had an enormous impact of behaviors.”

“Finding common goals is really needed.”

“Not reaching out and trusting teams would have made that [reaching our common goal] impossible.”

“I was pleasantly surprised how cooperative we became with each other.”

“People do not start out in trust.”

“Working with different teams [can be challenging] because they have different local goals.”

“How very important trust is to building high-performing teams.”

“Define the common goal makes you more efficient and motivates the team.”

“Trust others on the team, they have best interest in mind.”

It would say it was a very satisfying, compelling and educational day for everyone. I look forward to the next time I host this game.

On November 12th, I will be facilitating a first of its kind training for Agile Team members.   Through the use of simulation, I will help the participants reawaken dormant skills such as how to communicate with your peers, give (and receive) feedback, conflict resolution, decision making and other key soft skills each Team member needs to function in a fast-moving Agile Team.  At the completion of this one-day course, I hope to give participants a better appreciation of what skills are needed to communicate effectively, solve problems collaboratively, identify common communication patterns (and anti-patterns) and the application in the participant’s workplace.  Also, this is going to be a lot of fun.

In my work with Agile teams, I have observed that the greatest improvements of Team come when teaching the Team members soft skills.  These soft skills are more valuable because they allow Team members to connect with each other as individuals and foster true ownership of the work.  Too often people come to work on auto-pilot, go through the motions of their career and go home profoundly dissatisfied.  In my opinion, much of this can be traced back to a poor work environment which encourages isolation from the people we work with and the work we do.

With the Agile community’s strong emphasis on “individuals and interactions”, you would think as a community we would have some trainings that help people improve their soft skills, yet that is not the case.   Over the past couple of years, we have seen an explosion of training provided for leaders of Agile teams – the Certified ScrumMaster program is an excellent example – or we teach Team members technical skills – the classic two-day TDD class.  These are all really good things to teach people and they are useful to know.  They form a solid foundation for technical excellence and help create and sustain the Team environment.  However, they don’t teach people how to work together as a Team.

The simulation, named SIMSOC*, will begin the conversation of “How are we going to work together?  How are we going to make this time we spend together more valuable?”.  SIMSOC (pronounced sim-sock) can be thought of as a live-action version of “The Sims” combined with the cutthroat drama of “Survivor”.  The goal of each session is to remain “alive” and further your personal goals.  Some patterns of behavior will be more successful than others and it will be up to the participants to discover the the right strategy to remain alive by the end of the day.  No two strategies will be the same and there are no pre-planned outcomes.  Apart from a few basic “natural laws’, the participants are free to do as they choose, which creates fertile opportunities for cooperation and conflict.  By the end of the day, I hope to arm the participants with an alert mind, some valuable experiences on what types of communication and collaboration strategies which work and curiosity about the next steps they need to take to build and grow that awesome team that makes you excited to get up and go to work each day.

* SIMSOC was created by noted sociologist Dr. William Gamson to examine the role of leadership organization, power and social change and has been in use for over 40 years in both the business and educational world.

Mat Wayne ran an interesting session about overcoming resistance to pair programming organized around personas.  On each table there was a description of a different persona and some ideas on why that persona might resist pair programming.  Our job was to discuss in groups why the persona was resisting pair programming and some ideas on how to overcome the resistance.

I tried to make the case that gender differences was an important consideration in resistance to pair programming.  In a room full of (mostly) men, it was hard to be taken seriously, especially after the few women in the room were pretty vocal opposing my viewpoint.  However, I think the people in that room\conference self-selected to be interesting in pair programming.  The sample was biased toward ignoring the impact of gender on pair programming.  Remember, the purpose of the session was to help people who do not want to do pair programming to become more interested in it.

After talking with some friends, I think there are more gender dynamics at play when men and women work together programming and some of these might explain why women are not interested in (pair) programming.

• Pair programming requires two people to work in close proximity.  Some women might not feel comfortable sitting less than two feet from a male co-worker for most of the day or not be interested in the unwanted attention from men.
• Male programmers have a really strong geek hierarchy thing going on.  The more uber-geek you are, the more status you have and the bigger your voice on the Team.
• Get more than three men together and you begin to create a “locker room culture” that is a normal part of male bonding.  This is often characterized by seemingly harsh, personal put downs of your ideas by your peers.

I don’t think any one of these things is a definitive cause, but I do believe they add up and discourage women from participating on programming teams.  As coaches, we need to be mindful of gender and provide a safe environment.  It is not that women need extra help, just men need to be reminded to act like adults.

After searching and searching for this ballroom (this conference center is a bit of a maze), I finally found this session being held by some folks from Microsoft, Ade Miller.  They were talking mostly about their observations of working with teams in South America, but did talk about working with Teams in Asia.  This session was attractive to me because I was looking to see what other experiences people were having with distributed Teams and if my recent recommendations were on the right track.

Here is a list of ideas I jotted down while listening:

• Get good tooling to minimize the difference being in the Team Room and out of the Team Room.
• Select tools that are adaptive to the Team’s processes and ways of working together.
• Plan to travel; use the lower rate of the offsite people to offset the travel costs.
• Always have one guy from overseas in the main office.
• There will always be people difficult to synch up with due to time zone differences, so nominate a representative in the Team Room to advocate for them.
• Avoid component-based architecture and thinking to prevent local optimizations.
• Make sure every Team has a coach to remind them of the underlying principles and values of Agile.
• Have a list of books that people should read when onboarding.

As it turns out, I was mostly in the ballpark.

Just wanted to let people know that I will be the speaker at the XPSD meeting in September.  I will be talking about my experiences coaching Scrum teams in China and my insights on what essential skills a ScrumMaster needs to be successful.

Update: this was postponed until Oct 1st due to my knee surgery.  The topic will be the same – CEN 09/03/2009