5 Global Game Jam Lessons For Your Team

Leave a reply

This weekend, I had the experience of participating in Global Game Jam at IUSB. How does an event like “Global Game Jam” relate to your work? Keep reading….

What is Global Game Jam

In short, GGJ is a weekend-long event that starts at 5:00 PM Friday and ends at 3:00 PM on Sunday. Within that 46 hours, participants form teams and each team creates a game that is based on an announced theme. The IUSB Global Game Jam event, in my opinion, an unqualified success. How did we go from largely a group of strangers to two teams that produced  I Dream of Oleg the Unicorn and Heart Maze? This post has some of those observations and some suggestions for your “real” work.

Observations

A Purpose – The goal of the weekend was to create a game in 46 hours. The goal was unambiguous. People who were not interested in supporting that purpose were not present. And we weren’t just a group of folks individuals that were “working.” The purpose allowed us to really get excited about what we were doing.

Embracing Diversity – The event, and fellow participants, welcomed participants who were interested in making a game. Period. Game creation requires a wide range of skills; music, art, software, testing, imagination, organization, and many more. We collectively found ways to contribute, and to encourage others to contribute.

Visible Work Plan at the IUSB Global Game Jam

Loose Organization – The work we had to do was made visible and tracked. A light-weight backlog was on a whiteboard, the name of the person who took on the task was next to the activity. Notice I didn’t say the person who was given the task.We made the work that had to be completed visible, and people took it on. We even had a local reporter for the newspaper hear that we needed the sound of a fish, and she offered up her heretofore under-appreciated “fish” sound to the cause. Loose organization creates room for people to contribute.

Effective Leadership – We had a leader emerge on the team. The leader kept the goal of the weekend in front of us. Ideas were welcomed. Some of those ideas made it into the game, and others were struck from the plan as the weekend went on. The presence of the goal and a leader who could help the team decide, allowed for prioritization of the various ideas.

Nothing says “light mood” like high-fiving unicorns with an explosion and rainbows! Thank you, Tim Bell, for the awesome art work on this!

Light Mood – I have participated in similar weekend-long events. One reflection on this event relative to the others is that I left Global Game Jam feeling fairly relaxed. While I enjoyed participating in the 2011 Grand Rapids Give Camp and local Startup Weekends, they seemed much more exhausting.  Don’t get me wrong; both Give Camp and Startup Weekend were excellent events. But, the mood was much lighter during Game Jam, despite having a similar weekend-long event with a hard deadline.

Make Your Work Jam

Take the lessons from Global Game Jam, and look for ways to apply them to your work, and improve the effectiveness of your teams:

  • Make sure that the team has a purpose, and that it is kept in front of the team. If you don’t know what the purpose is, go find it.
  • Embrace the diversity of skills and perspectives on your team, and celebrate them. People likely have hidden talents that will make your team stronger. Create space for those talents to emerge.
  • Keep the organization of the work as light as possible. Remove what is unnecessary. Overweight organization is both productivity-killing and soul crushing.
  • Build leadership skills on your teams. Build people who can help share a vision, and rally others around the common goal.
  • Keep the mood light, and the energy high. Whether you are a team member, a stakeholder, or a manager, help foster a lighter mood on your team.

In conclusion, I want to take a moment to appreciate the team: Adam Valdez, Andrew Kroepel, Blake Robertson, Charlie Guse, Jen Purdy, Matt Forsythe, Matt Neumann, Sarah Gradeless, and Tim Bell. Your spirit and talent made a busy weekend very enjoyable.

Agile Sustainability; Culture, Management, and Metrics

Leave a reply

What are some keys to sustaining an Agile culture and organization? As part of our coaching, Susan DiFabio and I have been exploring sustainability as we iterate on our session for Agile 2012, entitled  “Keeping the Dream Alive: Keys to Agile Sustainability”

As we prepared for the Agile 2012 workshop, we had the opportunity to share at the Agile Cincinnati June meeting. We promised that group that we would share some of the references that we used when creating the workshop. Those references are:

Corporate Culture

“The Reengineering Alternative” by William E. Schneider
This book describes the model of corporate cultures that was referenced in the presentation.  It goes into depth about how the research was conducted, how the model emerged, as well as examples and opportunities for how to use this knowledge to help organizations leverage their strengths.

Metrics

“Measuring and Managing Performance in Organizations” by Robert D. Austin
Based on his doctoral thesis at Carnegie Mellon University, the author presents the reader with many insights on what actually happens when humans are measured as part of an organizational system.  Robert Austin’s book includes information from interviews with eight software measurement experts who represent a variety of opinions.  “Measuring and Managing Performance in Organizations” provides important information for anyone who is trying to use measurement to guide organizational decision making.

Management

Building Effective Teams: Miss the Start, Miss the End by Esther Derby
Esther is a thought leader in the area of organizations, team dynamics, and leadership. This blog post describes the manager’s role in creating an environment in which teams can become high performing. Susan and I have seen teams that have struggled, at least in part, because they lack the foundational elements of “real team” and “real purpose.”

Summary

To be agile, it is important to think well beyond the ceremonies and roles of a particular agile framework. We hope that this list of references helps you explore the topic of Agile Sustainability in more depth. We would also welcome you to let us know what materials you would recommend people study on this topic.

Lastly, thank you to everybody who attended the workshop in Cincinnati. We look forward to sharing with folks on Thursday afternoon at Agile 2012.

5 Ways to Keep Your Fishbone From Stinking

1 Reply

Do you have a tough problem you are trying to solve? Consider conducting a root cause analysis using a Fishbone Diagram. Here are five tips that can keep your analysis from stinking:

1. Have a sharp problem statement

Get this wrong and you’re wasting your time. Focus on one specific, observable problem. Think about ways you could measure the impact of correcting your problem statement. If the problem is measurable, there’s a good chance that you have a problem statement that is ready to be analyzed.

2. Find the right people

A former manager of mine use to say “availability is not a skill.” Get participants who will have the context and experience to generate quality insights. Make sure you get a diverse group of participants that will view the problem statements from a variety of perspectives.

3. Make time for it

Like so many things in life, the objective is not to rush through the activity. Schedule enough time whereby participants do not feel rushed. Do the analysis in one contiguous block of time. Make sure that participants are giving their full attention to the matter at hand, and that they are not disengaging either physically or mentally.2

4. Make it Visible

Be vigilant for conversation that is not captured in writing. A team can easily get into a dialog about the problem’s causes and forget to capture insights that are mentioned. Don’t let potential causes get missed. Make sure that all the participants have a pen and encourage them to write their observations on the diagram. If you hear a cause mentioned that isn’t captured, stop the conversation, get it written, and then go on with the analysis.

5. Get a Facilitator

Last but not least! Find a neutral party that has facilitation skills that can engage with your team. A facilitator will be focused on the mechanics of the activity, allowing participants to immerse themselves in the actual problem that they are trying to solve. A facilitator is instrumental in helping bring out the voice of all the participants, and can guard against the conversation going down paths that are not focused on the stated problem.

Summary

Using a Fishbone Diagram to visualize a root cause analysis session can yield powerful insights. Give your efforts the best chance of success by setting it up with a solid problem statement, and investing in facilitation to shepherd the team through the analysis.

Please share your thoughts on what helps or hinders the effectiveness of a root cause analysis.

Additional Information

1. A Fishbone diagram is the result of an analysis in which a team of individuals articulates possible causes of a specific problem statement, and then enumerates the possible causes of that cause. The individuals involved continue to do this activity recursively until they identify candidate root causes. The visual that results from this analysis will take on a fish-like shape.
2. Esther Derby and Diane Larson have some ideas on how to “Check In” in their book Agile Retrospectives: Making Good Teams Great. The book is definitely worth buying. Make sure people check their distractions at the door, and that you have the attention required for the activity.

Agile Sustainability

Leave a reply

What makes an organization that has decided to “go agile” one that is able to sustain the transition?

This week, Susan DiFabio and I presented on the topic of Agile Sustainability to the Chicago Agile Project Manager Meetup. The objective of the presentation was to have people leave the presentation with some ways that they could take action to make their Agile environments more likely to be sustained.

Click below to download the presentation and speaker notes.

Agile Sustainability

Activity Bingo – Make a game out of promoting cross-functional behavior

Leave a reply

Are siloed activities hampering your Agile team’s ability deliver work within an iteration? If so, consider encouraging more cross-functional activities. But, how do we make that happen? Let’s start by making cross-functional activities visible, and making it fun. We can set it up as a Bingo game.

Setup

Create a table with each team member’s name on the left column of each row, and the activities required to deliver the iteration work at the top of each column.

Make the charts big and visible. The more aware team members are regarding how they stand, the more motivated they will be to fill in the gaps.

Now let’s play the game

During the iteration, track the types of work that each team member contributes to meeting the overall iteration goal. To track the contribution, simply put a mark at the intersection of the activity and the person’s name. At the end of the iteration, look at the pattern that has shown up on your Activity Bingo board. If you are like some new Agile teams, the grid starts out sparsely populated (a holdover from siloed organizations).

Horizontal Bingo

As team members increase the number of ways in which they contribute to the team, your team may score a horizontal BINGO.

Vertical Bingo

Similarly as more team members swarm on specific activities and you develop real depth on the team, you may score a vertical BINGO.

Speed

If you want to try to build on the game, consider seeing how early in the iteration the team can end up with either a row or a column filled up.

Celebrate

Be sure to recognize the team’s accomplishments toward being a more effective team.

What techniques have you used to foster cross-functional behavior?

A special thank you to Susan DiFabio, Agile Coach, for co-authoring this blog. Thanks, Maria Matarelli, for your assistance in naming the game.

p.s. Check out another article on Agile teams, tasks, and limiting WIP.

Is Kanban really Agile?

5 Replies

Short Answer

Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.

Longer Answer

One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.

Individuals and Interactions over Processes and Tools

The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.

Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.

Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.

Working Software over Comprehensive Documentation

When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.

Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.

Customer Collaboration over Contract Negotiation

Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.

As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.

Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.

Responding to Change over Following a Plan

Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.

Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.

Summary

While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.

While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.

Find More Information

There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.

A special thank you to Eric and Susan for co-authoring this blog.

Susan DiFabio, Agile Coach

Eric Landes, Agile Coach

Innovation Park at Notre Dame First Monday

Leave a reply

Innovation Park at Notre Dame has announced a new First Monday event with the topic of “Social Media for Small and Medium Size Businesses.” Don Schindler will be presenting from 6:30 to 8:30 at this learning and networking event.

It is free and open to entrepreneurial folks who register. So, register for First Monday at Innovation Park. See you there.

Agile Community in Small Cities

Leave a reply

I attended Agile Coach Camp United States (Twitter #ACCUS) this weekend. ACCUS is an open space, self organizing conference. I created a video to share the results of the open space topic I proposed, building Agile community in small cities:

[youtube=http://www.youtube.com/watch?v=0ZcjCyY9I6M]

Please feel free to comment on other ideas for building community, especially if you have tested those ideas and have learned from it.

There can be only one

Leave a reply

Are you on a team where tasks seem to get started but not finished? Does the daily standup involve updates where individuals work on what seems like the same handful of tasks for multiple days?

Here’s a technique you can try for limiting work-in-progress. Instead of identifying task ownership whereby team members write their name on multiple task cards, ask each to use a single PostIt note with their name on it. Each person gets only one note with his or her name on it. Let’s face it, even if you have more than one task in the “In Progress” column, you can only work on one at a time. The sticky note is to be placed on the task that is being worked on at that moment. The note is moved throughout the day when changing tasks.

Here are some benefits of this approach:

Token to help address too much WIP

  1. Only one task can be claimed by any individual.
  2. The team now sees exactly who is doing what work at any moment.
  3. The team sees which tasks that are “In Progress” but not being worked on.
  4. Knowing what each person is working on makes it safer for team members to begin work on idle tasks.
  5. By no longer staking your claim to a whole set of tasks, you invite more collective ownership of completing the team’s work.

In addition to simply putting your name on a single sticky note, you could also capture data about context switching with this simple method. Write the date on your token. For that day, put a tally mark on the note each time the token moves from one task to another.

By using the date and tally marks on the card, you can get a sense for how much context switching is happening throughout the day. Perhaps thrashing is an impediment for your team. Of course, if you switch tasks six times and 5 tasks are completed, you probably don’t have a problem. If you switch six times and nothing gets to “Done,” there may be an impediment’s root cause to search for. Collect the notes throughout the iteration and look for trends in the data.

I hope you find this technique useful. Feel free to comment on the post.

SF Agile 2011 – Quick Reflections

Leave a reply

I authored most of this on my flight from San Francisco back to Midway last night…my Southwest flight did not have wifi for me to post it, however.

It’s Friday night, and I’m traveling home from San Francisco where I had a great experience at the inaugural SFAgile conference.The conference had high quality speakers, most of the speakers were also able to stay for the duration of the two-day conference. Not only did I receive a lot of value from the formal sessions, the conversations outside of the sessions were particularly valuable(See note 1 below).

SF Agile was an intimate, single-track conference that covered a breadth of topics, including Lean Startup, Lean UX, Teams and Product Stewardship, an Innovation Game, escaping timeboxes (new term materialized: “neo-post-agile”)… And that was Day 1!

Day 2 had topics that included  Agile Leadership, a panel discussion with audience-selected topics, lessons from Dr. Who, Coaching, the team/business bridge,  and happiness.  Although I neglected to put a mark on the “Value to Time Invested” retrospective chart (sorry Angeline), I will posthumously put it to “up and to the  right,” which we learned at the conference is where all good data on a graph goes.

Each day culminated in  a trip down Market street to Blu to socialize with other attendees. The conference’s size allowed for interaction with almost all of the attendees. This is the second conference this year that I have attended that had a single-track format( See Note 2 below).  I think I am a fan of the format. The single-track format creates a shared context for all the attendees. During breaks and after the day’s  formal activities, there is a common reference point that helps create cohesion as attendees can discuss a range of ideas presented throughout the day.

Thank you, thank you, thank you.
Thank you to all the sponsors for making the event very affordable for attendees.
Thank you for allowing me to share how lean principles and getting close to the customer and market were instrumental in shaping my path to being an entrepreneur.
Thank you Angeline and the rest of the folks who contributed to making this event a success. I hope to attend next year’s event.

For those of you who did not go to the conference, consider putting it on your calendar for next June.

Note 1. One example of the additional value was with Joshua Kerievsky’s who recommended the book The Secrets of Consulting by Gerald Weinberg, I actually had to put that book down to capture some of my reflections on the conference.

Note 2. KalamazooX was the other conference. That, too, was a valuable conference and I am way overdue to create a blog post about that. KalamazooX was a very nice one day conference focusing on the softer skills required in technology. Sorry Michael Eaton for the delay in writing about that conference. There was no flight home from Kalamazoo for me to draft it!