Project management: An Agile workshop

I first learned of Agile in 2010, when the development group at WebMD Health Services converted from waterfall to Scrum. It was a substantial transition for a large development team, taking several months to get in place.

What I found most interesting about the transition was the training. Rather than sitting through a series of presentations, designers and developers participated in a one-day workshop, where we formed a small company and tried to ship products. Of course, we got product out the door faster using Scrum.

When I joined Nike in 2011, using Agile was a substantial advantage for my group. Nike had just become the exclusive apparel vendor for the NFL, and I was asked to design software and processes quickly. Most importantly, there could be no unfinished projects — half-made, unused software would be a waste of resources, and my team was scaling up to handle the NFL business. Using Agile, I ensured that a functional version of the photo studio's workflow tracker was released every two weeks.

When I joined Moda in 2013, my director asked me if I could create some sort of Agile training. The best way to teach Agile — and especially Scrum — is to play games, so I designed two of my own. Team challenges are how I learned to appreciate the value of Scrum — both at WebMD, and later when I completed my ScrumMaster certification with the Scrum Alliance.

Designing a day-long Agile workshop is hard work, and it’s fun. I don’t recommend that everyone try it, because it’s time-consuming, and odds are your first workshop won't go as you expected — so be prepared for some humility and get lots of feedback.

That said, each workshop gets better, and if you are the workshop facilitator, you will get better at managing the inherent chaos of the whole thing.

My workshop consists of two construction projects — one before lunch, and one in the afternoon. I won’t give away too may details, because the unpredictable and somewhat random nature of both projects is what compels the team to collaborate and use Scrum to avoid chaos.

That said, here are twelve rules you should follow if you are planning to create an Agile workshop — and what you can expect if someday you are in mine:

Rule #1: No role playing

Most people are uncomfortable with the idea of “role playing” in a workshop. They also probably don't want to do trust-falls, sing, or hug complete strangers. Tell everyone right away that they will only have be themselves during the workshop — just as they would be in any workplace. (The facilitator, on the other hand, should be prepared to act out several roles.)

Rule #2: The team is self-organized and cross-functional

When the workshop team (typically 5-9 people) first gets together, they may expect the facilitator to assign roles and tasks. However, participants should be asked to self-organize, and leaders should be permitted emerge. The team also is likely to compartmentalize with role-based work (“This is my job, that’s yours.”) An effective workshop will prompt them to rely on their skills, rather than focusing on job descriptions.

Rule #3: The team is self-managing

Ask the self-organized team to accept requirements and manage their approach to the challenges set out. Again, they may think that the workshop facilitator is somehow “in charge,” which is why it’s important that the facilitator adopt another role — such as a product owner, client, or messenger, who will communicate the needs of the business but not take on a management role.

Rule #4: Require real things that are made with real tools

When designing games for an Agile workshop, it’s tempting to come up with something complex or overly abstract — for example, using some kind of point system to keep a score, or using a symbolic effort of work in the place of actual work. It’s critical that workshop participants make real things, with real tools and skills. These skills should not go beyond preschool construction and grade-school math. Making each project itself sufficiently challenging is up to the game designer.

Rule #5: Ask for effective status and planning meetings

Make sure there are moments within the workshop for the team to do a “daily scrum,” report status, and conduct sprint planning. During this meeting, no team members should perform any work, multi-task, or sit down. It’s an opportunity for everyone to be present.

Rule #6: Use working walls

Scrum prioritizes “information radiators” such as working walls, so that the status of all tasks is transparent. Ask the team to manage a working wall during their sprint planning. Again, the facilitator should not do this for them. (Tip: The first person on the team to pick up a Sharpie is the emergent ScrumMaster.)

Rule #7: Provide clear “done” criteria

Don’t provide fuzzy requirements, and don’t accept “close enough” output. Most teams are more than willing to accept and meet clear, measurable requirements, which the facilitator must provide for each product feature. The definition of “done” should be measurable enough that another team member can perform a QC role and confirm that the product meets expectations. Broken and wrong products don't make money. Accurate products ship.

Rule #8: Timebox the work

Sprints should always have time limits, and the time available should be visible to the team. I’m a big fan of the mechanical 12-inch Time Timer, but the iPad version also is a good choice.

Rule #9: Create emerging requirements

If our fictional business environment had no emerging requirements, there would be no need for Agile or Scrum. It's up the facilitator to make sure that the team confronts unexpected challenges — as long as these challenges can be met and overcome with collaboration, teamwork, and the understanding that skills are more important than job descriptions.

Rule #10: Require iterative product releases

Nobody will learn anything from one waterfall project that’s predictable from start to finish. Because the team has to manage emerging requirements, the facilitator should ask them to focus their sprints on releases of functional product. There may be more work to do on the backlog, but with every iteration a complete version of something must be in place — and the final, accepted version of the product should be something that nobody could have predicted when work began.

Rule #11: Ask for team retrospectives

The facilitator should prompt the team to conduct a brief retrospective at the end of every status meeting. “What went well?” and “Where can we improve?” are the key questions. The project will become more challenging with every sprint. A good team will adapt their processes and become more fluid in their roles as they go along. The retrospective is the team’s opportunity to prepare for change.

Rule #12: Have a payday

Each workshop project should be framed in the context of the company making a profit, and at the end of a successful project, the facilitator should hand out some Monopoly money (and maybe cookies or cupcakes).

Sound like fun? I ran my Agile workshop at least a dozen times at Moda, and the team feedback was positive and helpful. Thanks to feedback, I added more details to each session, and I got better at predicting what people might do in unpredictable circumstances. Every workshop was different, and participants usually got out their phones to get keepsake photos of the final products. That was a pretty good measure of success for me.