Agile Learning Labs

Agile Retrospectives - Part 2

In my first post about retrospectives, I described what a retrospective is, why you want to do them, and described the Retrospective Prime Directive.  Now it's time to talk about how to do a retrospective.

A Retrospective Agenda

In Agile Retrospectives: Making Good Teams Great Esther Derby and Diana Larsen provide an excellent basic agenda for a retrospective:

• Set the Stage
• Gather Data
• Generate Insight
• Decide What to Do
• Close

Let's look briefly at each of these.  I strongly recommend reading Esther and Diana's book for a more in-depth treatment.

Set the Stage

At the beginning of the retrospective, you want to establish a shared understanding of the goal: You are looking for an area to implement some improvement, based on the experiences the team just had.

This is also a good time to identify the comfort level and level of engagement of the participants.  If it turns out that the participants don't feel safe, or would rather not be in the retrospective, it will probably be much more productive to deal with those issues instead of moving ahead with the retrospective as planned.

Gather Data

This section is all about 'what': what happened during the period under examination.  We’ve learned that it is always best to have some measure of structure. Simple exercises, many of which are detailed in Esther and Diana's book, can help keep your thinking fresh and your discussion on-topic.

Time-line exercises are extremely popular for this.  You can use index cards or sticky notes to build a time-line on a wall, with each team member contributing as many events to the time-line as they can recall. 

This is a good time to bring in the project artifacts: burn-up and burn-down charts, story cards, lists of bugs, data about build breakages, customer comments, or any big visible charts that the team uses. 

Whatever method you use, the goal is to gather enough data to help the team see what happened as completely as possible, from as many points of view as possible.  The longer the time period being retrospected upon, the more important this section is.

Generate Insight

The section is about 'So What?' as in: So, what does it all mean?  This section is also about 'why', as in, why did these things happen?  It is not about “who”—remember the prime directive and be careful to avoid finger-pointing and blame.

During this phase the team will do activities designed to:

• Find patterns in the data
• Find the most important items
• Deepen understanding
• Find causes and effects
• Identify possible solutions or improvements to try

Decide What to Do

This is sometimes called 'Now what?'  The team has looked at what happened, come to some understanding about how and/or why it happened.  Now it's time to pick something to do differently going forward. 

It's generally best to pick only one area (maybe two, maybe) to improve.  The idea is for the team to make steady forward progress, not to get overwhelmed trying to fix everything all at once, however strong the inclination to do so may be.  A team that is successfully addressing one new area every week will feel great about it.  A team that is trying to fix five areas but failing to take action on four of them will feel disheartened. 

Pick things that are under the team’s control, and within their power to implement.  It's not helpful for a team to decide to hire more testers, if they don't have the authority.  Much better to pick an action the team can implement, like: Improve our testing by automating more test cases.  Be specific.  The outcome of this section of the retrospective should clearly identify who is going to do what by when.

The change should be viewed as a trial, or experiment.  It should be implemented, and then the results examined to determine if the change actually had the desired impact.  Not all process improvements work as expected!  So, along with who will do what by when, identify when you will check back in to judge the effectiveness of the change.

Close

The team has done some good work.  They are putting in the time and energy to continuously improve.  Take a bit of time to recognize and celebrate this.  You want the team to walk out of the retrospective energized and more bonded than they walked in.

An appreciations exercise is a good way to end a retrospective.  Invite people to call out specific things that they appreciate about their teammates.  The more specific the appreciation is, the better.  Use the format: "I appreciate <person> for <something>."  Here are some examples:

• I appreciate Brad for staying late to fix the broken build.
• I appreciate Kira for being patient with me when I was grumpy on Tuesday.
• I appreciate Kai for helping me debug the redraw issue.
• I appreciate Justus for his deep knowledge of Visual Basic; it really saved us this iteration.

That's it!  Go forth and improve.

Get your ScrumMaster certification with Jeff McKenna and I before the October testing deadline.  Hurry, this class will fill up quickly.

Agile Retrospectives - Part 1

By Chris Sims

Retrospectives are the agile team’s most powerful tool for facilitating continuous improvement.  We’ve all encountered teams that make the same mistakes and suffer the same pain over and over again.  The good news is that it’s possible for just about any team to break this cycle by investing as little as an hour a week in learning to use retrospectives to systematically and incrementally improve performance.

Agile teams continuously inspect and adapt, resulting in ever-improving performance, and happiness.  The retrospective (some call it a meeting, while others refer to it as a ritual) that is held at the end of each and every sprint is the primary means by which the team is empowered to improve, as it allows learning and insights to be captured while experiences are fresh, and before negative patterns have a chance to harden in place.  The goal of every retrospective is simple: to identify one or maybe two areas to improve, and to create an action plan to implement the changes.

Some people new to agile have experience with traditional 'post-mortems' or 'lessons learned' sessions.  Traditionally these are held at the end of a long project, and often generate long lists of 'plusses' and 'deltas' that are forgotten almost as soon as the meeting ends, amidst disgruntled mutterings about “barn door” and “the horse has bolted.”

In contrast, agile teams hold retrospectives regularly, at all levels of a project.  Common types of retrospectives include:

• Iteration
• Release
• Incident
• Project

While generating the traditional laundry list may be initially cathartic, it quickly becomes frustrating to see the same items show up over and over:

"Once again, we didn't have enough time for testing."
"Integrating the subsystems was painful."
"Fixing bugs kept us from working on the new features."
"It took too long to get database changes from the DBAs."

It feels much better to identify a single area to improve, and then do something about it.  Teams that effectively use retrospectives feel a strong sense of empowerment as they continually improve the way they work. 

How long does a retrospective take?  A rough guide is 30 - 60 minutes of retrospective for every week being retrospected upon.  Teams often find that as they get used to the process, they need less time than when they first start doing retrospectives.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

This is The Retrospective Prime Directive.  It was created by Norm Kerth, author of Project Retrospectives: A Handbook for Team Reviews, and he explains it this way:

At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated…

The prime directive sets a productive tone and spirit for a retrospective.  Of course, the team knows much more now, and would do things differently.  Without mistakes and shortcomings, we’d never uncover new opportunities to improve.  The pain and struggle that led to learning should be honored.  In this way, the team can benefit and build on the lessons and the learning that took place.  If we finger-point, blame, and embarrass, people will be unwilling to share; the opportunity to improve will be lost.

Tune in for part two, where I will walk through a retrospective agenda.

Scrum Master Certification Workshop with Jeff McKenna

By Chris Sims

What: Certified Scrum Master Workshop
When: Saturday and Sunday, September 12 & 13
Where: Redwood City, CA
Who: Jeff McKenna and Chris Sims

Get in the class now!

This two-day experiential workshop with Scrum co-founder Jeff McKenna and Agile Learning Labs' Chris Sims leads to ScrumMaster certification through the Scrum Alliance, and is worth 14 PDUs through the Project Management Institute.

What you will learn
This course provides a solid overview of Scrum, and delves deeply into the role of the Scrum Master. The topics covered include:

• Brief history of Scrum
• Roles and responsibilities
• Metrics
• Requirements gathering and management
• Estimation
• Planning
• Prioritization
• The rhythm of the Scrum Sprint
• Retrospectives
• Facilitating self-organizing team dynamics
• Simple tools for managing Scrum projects
• Skills for succeeding as a Scrum Master

Who should learn this stuff
This workshop is for anyone who needs a solid understanding of Scrum, including: developers, testers, business analysts, technical managers, project managers, program managers, product managers, and even C-level executives. And, of course, it is a must for aspiring Scrum Masters.

Learn from a Scrum founder 
We are thrilled to be partnering with the one-and-only Jeff McKenna to put on this workshop. Jeff was a member of the very first Scrum team, and brings over 45 year of diverse experience to the classroom. You will have plenty of time to ask Jeff questions, and hear war-stories from one of Scrum’s progenitors.

Learn by doing
Scrum is all about teamwork and dynamic interaction, so we wouldn’t be setting a very good example if we spent 2 days lecturing at you from a podium. Instead, you will be playing serious learning games, modeling processes through project simulations, madly scribbling on index cards, creating charts, and cementing the learning through retrospective discussion. In short, you will learn Scrum by doing Scrum.

Learn in a fun environment
Who wants to be entombed in a corporate training center on a glorious fall weekend? Class will be held in a bright, cheery room overlooking Redwood City harbor, where you can take your catered lunch out on the deck and get some sun and fresh air. Feel free to dress comfortably (think college campus casual, not casual Friday at Dunder Mifflin or Initech ).

Keep learning after the class
We aren't satisfied to stamp 'Certified' on your forehead wish you luck; we want to help you succeed with Scrum where it counts, back in your real world. That's why this class comes complete with 2 hours of follow-up coaching from Chris Sims. This is two hours of Chris' time that you get to use any way you see fit (note: uses of Chris that violate the Geneva Convention or international treaties are prohibited). We'll also be organizing a "class reunion" at a local pub, so you can check in and compare notes about how you've adapted what you learned out in the world.

Beat the October test deadline!
Anyone taking a Certified Scrum Master course after October 1st will have only 90 days in which to take and pass the online certification exam. Participants in our September workshop will receive their certification without the need to take the exam.

 

Jeff McKenna

Jeff McKenna has been involved in software development for some 45 years. During that time he has participated in every aspects of product development from implementation and test, through architecture and design, all the way to sales and marketing. Since the late 1980s Jeff has focused on the process side of development. He consulted on the very first Scrum project in 1993. He has taught, coached and mentored agile teams using Scrum and Extreme Programming practices for small and medium sized projects. His clients range from small startups to established enterprises. Jeff currently works Serena Software as Agile Evangelist. Jeff is a Certified Scrum Coach and Certified Scrum Trainer. He can be contacted at agile.action@gmail.com

Chris Sims
Chris Sims helps software development teams improve their productivity and happiness. His approach combines experiential training, coaching, and even direct technical contribution.

Chris is the founder of Agile Learning Labs. In addition, he is chair of the IEEE Technical Management Council of Silicon Valley, and is on the board of BayAPLN, the Bay Area chapter of the Agile Project Leadership Network.

Chris is a certified scrum master and practitioner, who has been leading successful agile software projects since the turn of the century. He has made a living in roles such as: Scrum Master, Product Owner, Engineering Manager, Project Manager, C++ Developer, Musician, and Auto Mechanic.

Get in the class now!

Fun & Games & Aha moments at the Bay APLN

by Hillary Johnson

A couple of weeks ago, Chris was the guest speaker at the Bay Area Agile Project Leadership Network's monthly meeting. It was an evening of game-playing and simulations. One of the most popular is a simple game that takes under five minutes to play, but always blows the tops of people's heads off by demonstrating concretely and irrevocably just how deeply multitasking cuts into productivity and even quality. This particular exercise led to some insightful conversations and aha moments, including:

• The majority of aviation accidents that are caused by human error are the result of unexpected context switching
• Multitasking exercise can make the case for "office hours"

Other highlights from the debriefs around the games included these observations, captured on Post-Its:

• It's a turnoff to be "worked on"
• The team has better visibility into a problem than an outsider
• It's quicker to get into a tangle than it is to get out of one
• Boundaries are movable, depending on your assumptions
• The team can iterate faster and better than the manager

The BayAPLN meetings are open to all, so please join us for the next one on August 18, when the inimitable and entertaining David Chilcott will show you how to have a meeting that doesn't suck (hint: "What if you managed your meeting like a sprint?") . And if you want to play games with us, check our hompeage for upcoming classes and other free events where Chris will be speaking. Or turn up for Agile Open California, where there will be lots and lots of games and even more ahas.

"Embrace change to add more value!" and other "aha!"s

by Hillary Johnson

Every time we run an Agile Project Management class we tweak it slightly, based on what we've learned in the last one. Inspect and adapt, as they say... err, I mean, as we say.

One thing we noticed happening over an intensive two days period is that people tended to generate many more insights than they can retain. "Aha" moments that seem memorable at the time have faded after the two day barrage of new information. How to capture the spontaneous learning as it occurs and preserve it, without disrupting the flow?

Our solution: Create an "aha!" wall where students can capture their immediate insights by putting up sticky notes at any time during the two days. These ahas formed a significant part of our retrospectives at the end of each module, and make a fantastic mnemonic take-away.

As we strive to structure our workshops to resemble agile projects as much as possible, we framed these ahas as representing the "learning value" the students were generating during each educational "sprint." Needless to say, this maps quite nicely to "business value" and demonstrates the beauty of incremental delivery in a tangible way.

This week we had thirteen very bright students show up for a two day workshop offered through the Bay Area chapter of the PMI, most of them PMPs, some with a high level of agile awareness, others new to the field.  Here are some highlights from their wall of over fifty "aha!"s. Reading over them, I think these could easily be chapter headings for a book on Agile Project Management:

Retrospective = lessons applied = improved output and flow.

Fail safely; fail softly!

Work becomes fun!

Things that are visable get more attention--and get done!

Embrace change to add more value.

If you won't need it, don't do it!

Responding to change means changing the plan.

Document to the extent that value is added to maximize ROI.

Focus on done, not doing.

Slow down to increase output.

Early delivery, early revenue = "compound interest"

A lot of the students in this class expressed an interest in returning for our upcoming Certified Scrum Master Training on August 12 & 13, which Chris will be co-teaching with the inimitable Jeff McKenna, which we have yet to formally announce. If you want to join them for some more ahas, save the date and either join our mailing list or check back early next week, when we should have details and a registration page.

Are you coming to Agile Open California?

by Hillary Johnson

Last year, Chris was on the coordinating committee for Agile Open California, a grassroots Open Space conference for and by the local agile development community. This year, the privilege falls on me. I was bit by the Open Space bug last year, and have now been to several. The format lends itself to surfacing all kinds of ideas and expertise, and fostering the kind of feverish engagement that leads people to revolutions in their thinking. If you're a die-hard agilista, or just curious, please do join us this year on October 15 & 16 at Fort Mason, in San Francisco (there's a SoCal sister conference in September). If you register early (as in now), it's a mere $150, which is a pretty good price for guaranteed transcendental enlightenment.

Here's a blog post by David Carlton about a session called I hate Pair Programming that should give you a fair idea of the kind of content to expect. And below are some images to whet your appetite:

Artist Elizabeth McClellan captured many of the sessions for posterity.

Here people are swarming around the "marketplace," where participants have posted sessions they'd like to lead--or attend.

And here is Chris looking terribly dignified and businesslike.

'State of Agile' Survey Open

By Chris Sims

The fourth annual State of Agile survey is open for participation.  The survey is sponsored by VersionOne Software.  Over the past 3 years, the survey has provided some interesting insight into what agile practices are actually being used, and what benefits companies are getting from going agile.

I just wrote about the survey for InfoQ.  Just because you read this blog, you can get a sneak peak.  The rest of the world will have to wait until it hits the InfoQ front page on Monday morning. 

Cheers,

Chris