Sprint Retrospectives are for getting better…all the time.

Scrum teams conduct a Sprint Retrospective at the end of every Sprint to find ways to improve the way they work together. It turns out, having really effective retrospectives requires some specific conditions to exist to allow improvement to happen. All too often, the team’s environment doesn’t support them expending effort to make real, substantial improvement. Here’s a simple test for a Scrum Master: “Is my team improving every sprint?” Sounds obvious but it needs to be answered, and answered honestly. If the answer is “no” or the answer is unclear, there are some simple things that can be done to help (well, some are not so simple).

Common Retrospective Patterns

First, I want to share some of the anti-patterns I have experienced with some teams I’ve worked with:

There is already too much work in the sprint to make improvements.

The team rushes into problem solving right away without much discussion leading to weak outcomes.

The same impediments are discussed at every retrospective.

The same activities/questions are used for each and every retrospective; they have become boring and repetitive.

The impediments that are discussed are too big for the team to solve.

The team has stopped having retrospectives.

There are many others, but this is a good, common list of retrospective anti-patterns that I often hear about when I work with teams.

To help alleviate some of these problems, here are 6 actions you can take:

3 actions to allow continuous improvement to happen and

3 actions that help retrospectives work better.

3 Actions to Allow Continuous Improvement to Happen

These 3 are the “not so simple” actions since they require a real change to how work is planned and who plans it. This requires a commitment from leaders to create an environment of continuous improvement.

Allow the team to determine their Sprint capacity.

I know many teams, including their managers, who say that the team determines their own capacity, but when you dig into it, we see that there are other things at work undermining the team’s autonomy in determining their capacity. Many teams are hesitant to push back on the Product Owner (PO) who is asking for a particular story in a particular sprint, even though they don’t believe they can finish it. In fact, any time the team is taking on work that they are not convinced they can get to “done” in a sprint, that is a sign that they are not truly determining their own capacity. The Scrum Master plays a key role in helping the team only agree to the work they can complete and no more.

I often tell teams “you should be happy when Sprint planning is over, convinced you will get everything done by the end of the Sprint.” When I say this, I get puzzled looks or disbelief. If your team isn’t leaving Sprint Planning very excited, convinced they will succeed with their Sprint plan, this is a clear sign that they don’t have control over the amount of work they commit to.

I recently surveyed a large group at Adobe that has many teams, distributed around the world. One question I asked was whether they put all work that the team does in the Product Backlog and the answer was mostly “yes”. I was very encouraged that they were making the team’s work visible. However, the results of the next question were very telling about what was really going on. “Is work added during the Sprint?” The answer was also a resounding “yes”! What was going on? I asked around and discovered that planned work went in the backlog, but many unplanned items were creeping into the Sprint and coming from many directions; sometimes from the PO, sometimes from a manager, and sometimes from the business-side. This is in direct contradiction to how Scrum is supposed to work. We make all the work visible by putting it in the Product Backlog and we let teams focus on their Sprint goal by not interrupting them. This also undermines item #1 above since the team now has no way to truly determine their capacity if they aren’t the ones pulling the work into the Sprint during Sprint Planning.

In a talk I attended some years back by Jeff Sutherland, the co-creator of Scrum, he stated that one of the primary reasons for having uninterrupted periods of work (Sprints) was to stop the thrashing that often goes on within teams and derails their focus and productivity. Teams who can really focus become much more productive, not to mention, happier and more fulfilled in their work. If you want to understand this concept more, check out this TED talk by Mihaly Csikszentmihalyi on Flow: http://www.ted.com/talks/mihaly_csikszentmihalyi_on_flow and also, The Progress Principle by Teresa Amabile and Steven Kramer.

The team has permission to add work to the Sprint to make improvements.

I regularly facilitate retrospectives for teams and when we get to the part where they are deciding what they are going to improve in the next Sprint, they often express concern that there is no time since they have too much work. How do they know how much work they will have in the next Sprint if they haven’t done Sprint Planning yet? This concerns me because in Scrum, self-organizing teams determine what gets into the Sprint Backlog so they should have direct control over that.

Also, if the leadership has not given the team permission to spend time improving, then when will it happen? Later? In the competitive world we live in, there is no “later”. We will always have very urgent and important features to implement. Improvement is a investment you make to go faster later. If you don’t pay it and your competitors do…well, you know what happens.

Here is a simple agreement that teams and leaders should discuss: every Sprint, the team puts one improvement at the top of the Sprint Backlog before any product work is planned. This reinforces its importance and ensures there is time to make it happen.

3 Actions that Help Retrospectives Work Better

I too frequently encounter a level of frustration with retrospectives from teams who regularly do them, but have found them unsatisfying. What I often discover, after discussing how they conduct them, is a lack of the experience and skills required to do them well. For my first 3 years of implementing Scrum, I followed the usual retrospective pattern and asked the following 2 questions:

What went well?

What do we want to improve?

After a while, these retrospectives become mind-numbingly boring. The stubborn keep at it and the disenchanted abandon them altogether. I was one of the stubborn ones 😉 Others learn a few basic activities like sailboat or +/delta and then repeat them, over and over again, every retrospective.

I had the wonderful privilege to learn retrospective facilitation from one of the co-authors of Agile Retrospectives book, Diana Larsen. This class completely changed how I saw retrospectives and when I put into practice the techniques I learned, I saw much better outcomes.

Here are 3 things you can try to improve your retrospectives:

Follow the retrospective pattern.

I won’t go into too much detail about what pattern Diana Larsen and Esther Derby have defined for good retrospectives. You can read it yourself in their book. I will focus on the most important step so that you may understand why the basic “two-question” approach is lacking in effectiveness. Here is the basic pattern they define:

Set the Stage

Gather Data

Generate Insights

Decide What To Do

Close

The “two-question” approach mentioned above are two questions that should be asked in the “Generate Insights” portion of the retrospective. Diving right into those two questions skips right past “Set the Stage” and “Gather Data”. What exactly is “Gather Data” then? This is where the team answers the “What?” question. In other words, “What happened in the previous Sprint?” Not “What do we think about what happened?” or “What do we want to do about it?”, just the facts, the events, the good, the bad, and the indifferent. Some examples might be: the build broke in the first week, bug counts went up, Sue got sick, Jayanth and Alexei paired on a really difficult story, or whatever. Just record the things that happened. You should spend the bulk of the time (~40%) on this step. Why so much? In order for groups of people to come to a common understanding of what happened and to make good decisions about what to do next, they need time. Lots of it. Spend the time on this part and the next two stages move more quickly. Which also means that you need to make sure your retrospectives are long enough for this to happen. How long? 75-90 minutes is a minimum for good improvements to emerge. Don’t believe me? Try it and find out for yourself.

Mix things up.

At Diana Larsen’s urging, I went on to become a Human Systems Dynamics Professional with the Human Systems Dynamics Institute (HSD) led by Glenda Eoyang. The organizational change work they do is rooted in the idea of human systems as complex systems. They have learned from complexity science about how attractors work in complex systems. There are a number of attractors in complex systems but one type is called a periodic attractor. Scrum is a periodic attractor because of the iterative nature of Sprints. Every two weeks (or so), we review, we plan, and we work. There is a danger with periodic attractors though. In Coping with Chaos, Glenda Eoyang writes that periodic attractors build resistance. When I read that, my head nearly exploded. Does this mean that holding regular retrospectives can cause resistance to change? Then it dawned on me why the Derby and Larsen book recommends changing the activities for retrospectives on a regular basis; to mix things up a bit. The analogy that came to mind is of someone rubbing the same spot on their arm. After a while, they don’t feel anything. Doing the same thing for each retrospective, over and over again builds resistance in people. They become immune to taking real action and getting to the heart of their problems. They go through the motions and get out of the meeting as quickly as possible. Groups like these often rate retrospectives as their least favorite Scrum meeting.

(Aside: HSD has an activity called “Adaptive Action” which is virtually identical to retrospectives, following the same basic pattern, albeit with different terms.)

A good Scrum Master will seek out training and other resources for retrospective activities to continuously improve their retrospective facilitation. As with all things agile, we continuously seek ways to improve our implementation of agile methods. A good starting place is the Agile Retrospectives book but there are other resources you can draw on such as Retr-O-Mat, Tasty Cupcakes, Retrospective Wiki, and many others. I strongly suggest learning the pattern and the purpose of each step first. The other resources then can fill in when you are designing your retrospectives.

Focus on one improvement at a time.

In fast-paced, complex work, there will always be many problems uncovered, issues to resolve, and improvements to be made. It is the very nature of the work itself. During retrospectives, teams will regularly identify many issues. In fact, the list can be quite long and daunting, making it seem as though nothing will ever improve. A very common pattern with team retrospectives is that they choose a list of actions to take, sometimes 5, or even 10 actions. Sadly, because of time pressure, many of these actions are not taken, often none at all. During the next retrospective, the team finds themselves talking about the same issues, Sprint after Sprint. This can really demoralize a team that is struggling to improve.

The concept of “small batch size” from the Theory of Constraints by E. M. Goldratt teaches us that to increase speed (and here, I am referring to the speed of improvement), small batches move faster through a system and don’t cause the work in progress to become a bottleneck. Small incremental improvements are easier to focus on, as well.

As an experiment, for your next few retrospectives, choose only one improvement. If you want, you can place all the other actions in an “improvement backlog” but only commit to one action for the next Sprint. Most importantly, make it actionable by being very explicit about what exactly the team is committing to try. Don’t commit to things like “the team will write more unit tests” or something as equally fuzzy.

Answer these 5 questions to make a weak retrospective outcome stronger:

What? – identify exactly what experiment you are going to run (e.g. Dave and Jo will pair program on the riskiest story in the next Sprint)

Why? – state the hypothesis of why this experiment can be an improvement (e.g. Pair programming will reduce the risk of error)

Who? – what single individual will ensure that this happens (e.g. Jo will own this action)

When? – what date will this be done by (e.g. Jo will invite the team to a meeting at the end of the first week)

How? – how will the team know that this happened (e.g. at the meeting, Jo will demo all the passing tests and discuss other technical details at the meeting)

Some will recognize that this is very similar to SMART goals. I prefer this set though because they are easier to remember (for me at least) and they make it clear that this is an experiment, i.e. it can fail, too! We learn the most from those experiments.

Choosing only one action increases the chance that it will actually get done and over time, an accumulation of single actions start to add up to a lot of improvement. Choosing only one improvement aligns very well with one of the 5 Scrum values: Focus.

So…

Leaders who make it clear that investing in continuous improvement is extremely important and not optional enable their teams to creatively accelerate their work and increase speed to value. Scrum Masters who invest in improving their retrospective facilitation skills will increase the speed at which the team learns.

Lastly, since you read all the way down to the bottom, here is a funny video from the Netherlands on improving your retrospectives:

When it comes to estimation in Software development, the difficult question to answer is when can we go to market? and when can we release the product or service? These are difficult questions, both from the business perspective as well as the development perspective.

There has been a lot of conversation in the agile community around User Stories and use of Story Points to size the product backlog items. What is often lost when teams adopt this technique is the value of team heuristics, as in team experience and the importance of relative sizing. These put together and followed with some discipline allow the team with the ability to forecast – as in over discrete periods of time, sprints, express an ever accurate answer to the questions:

How much by this date?

or

All this by when?

If no one is asking these types of questions at the end of each sprint then you may be in danger of falling into the cargo cult scrum trap, as in following a ritual of sizing product backlog items for ritual sake.

So what does heuristics really mean?

In a nutshellheuristics refers to experience based techniques for problem solving, learning and discovery, one which is good enough approach to finding an answer, where the perfect answer is not knowable or would be too expensive to learn.

So, if you are familiar with how most sciences work, you have probably encountered the use of heuristics before. For instance, rather than predicting exact ratios of chemicals for a reaction, chemists use heuristics as guidelines in predicting how various chemicals will react. Similarly in engineering for instance aircraft designers use heuristics by considering coefficients of lift and drag to point them in the right direction, with the design empirically refined based on experimental evidence.

In essence to answer either of the questions stated above there is a heuristic alternative to the careful reasoning thatoccursin the long cycles of phased approach in gathering requirements, analysis, design, development and test. Thisheuristic alternative works well for estimation and this is in spite of sometimes serious errors. The key is to ensure the errors are bounded across short time intervals, with frequent pauses assess the outcomes and inform what to do next. Of course Scrum provides for a natural cycle of pauses at the end of each timebox, where the team can take stock of the outcomes as well as assess the steps the team actually took vs. assumed what they took, yes essentially these being the sprint review and end-of-sprint team retrospective.

First Order Estimation

So what is the first order of estimation, well it is something we all do so naturally and effortlessly when it comes to driving a car to riding a bike to walking in a busy mall, else surely we would be running into each other most of the times. I mean when is the last time you got out a measure tape when changing lanes on a freeway or overtaking to ensure you have the most accurate measurement in distance or speed.

In essence the first order estimation I refer to is a relative measure, in this case of work items (user stories) to one another. To me it is similar to coefficients of lift and drag considered in aircraft or even car design. Its just that in this case these estimates can be now be thought of as being the teams coefficients, one that corresponds to the team that is going to do the work based on their perspective for product backlog items as opposed to anyone elses.

Team’s coefficients

There are teams that only look at their teamcoefficients, user story points, when planning a sprint. This may well be all that is needed for planning, but in truth this is only the case for a teams that have been together for a long time, have experience of working with each other and have established team heuristics, their rules of thumb.

Teams that are new or new to working as a scrum team often miss out the need to assess the team capacity at a more granular level of planning, one that breaks a product backlog item (user story) into actual tasks that need to be performed in order to get to done!, before making team commitments. So it is best for a team to be mindful and disciplined towards developing the team heuristics and continued reliance on wisdom of the crowd to decipher difficult problems that includes estimation.

To do this start with having a stable team one that takes a disciplined approach in their scrum ritual meetings during the sprint. This includes when refining backlog items and/or sizing using story points to when planning out by defining tasks along with task level time estimates as this is what will help shape the teams commitment to the plan that appears in the form of a sprint backlog.

Eureka!

Daniel Kahneman, in his book Thinking, Fast and Slow, points to how judgement happens, andwhile it is a complex function of the brainwhat he points to is what Psychologist have to offer based on their observations supported by what Neurologist tell us about functioning parts of the brain. In essence we have evolved to with two modes of thinking, called System 1 and System 2 as coined by psychologist Keith Stanovich and Richard West.

Where System 1, evolutionary the oldest, the part that is responsible for fight or flight and ingrained to our survival instinct, operates continuously and generates assessments of various aspects of the situation with little or no effort. This basic assessments plays a vital role in intuitive judgement, as this routinely substitutes the more difficult question being asked of by System 2, the essence of heuristics.

Where as System 2 thinking considers, only if it must, the difficult to answer questions the one that System 1 doesn’t readily offer an answers to, and it triggers many other computations including basic assessments acting as a mental shotgun according to Kahneman. He points out the word heuristics comes from the same root word as does the word eureka, and is technically defined as a simple procedure that helps find adequate, though imperfect answers, to difficult questions.

I have heard something multiple times this week, something that has me a bit concerned. The gist of the sentiment is something like this: “Oh, we discourage the developers from talking to customers; we don’t want them to be distracted from their work or to build a bunch of stuff that’s not in the plan”.

If you are working in an agile environment, this sentiment is outdated and harmful. We want developers to understand the customers and have empathy for them, and there is no substitute for direct interaction for building that understanding.Let me start by discussing the agile mindset regarding developer-customer interaction, then address the concerns expressed in the statement.

Cross Functional Teams

Agile, and specifically scrum, relies heavily on the idea that cross functional teams build better stuff. While product managers, sales people, and similar roles have responsibility for understanding the customer problem space and communicating it to developers, and agile teams typically have a Product Owner for a similar purpose, agile teams see that expertise as a part of their team, not a separate group. The most effective development teams try to learn as much about the customer problem space as possible. They make multiple small decisions every day about how to solve customer problems. Requiring all knowledge about those problems to be siloed in one person or group, and separating that group from the team creates an unnecessary bottleneck to the system. Once developers understand the Why of what they are developing, they become much more engaged, championing solutions that they think will best help their users.

Empathy

Great products emerge from experimenting in the overlap between the customer problem space and the technical possibility space. Developers know the second space well, but can only know the first space through experience either as an actual customer or through talking to customers. In my experience, great products are rarely built without the developers having a good idea of how their customers think, and more importantly, empathy for their problems. Chip and Dan Heath give a great example of this in their book Switch. They describe a Microsoft team full of brilliant developers. They were certain they were writing brilliant software, but when the usability group tested it with users, six out of 10 customers couldn’t figure out how to use the new features. When they told the programmers, their response was, “Where did you find six dumb people?” To increase empathy, Microsoft brought the programmers into a usability-testing lab and put them behind a two-way mirror. When the programmers watched a real customer struggle with the software they designed, the programmers immediately started thinking about ways of changing it. They were developing empathy for the users, and instead of contempt for their ineptitude, they developed an intrinsic desire to improve the software to better meet the needs of the customers.

But what about those concerns?

“…we don’t want them to be distracted from their work…”

In his book Radical Management, Steve Denning describes a shift in the way that we describe the high level goals of everyone at a company. He proposes that the primary goal of every employee is to “Delight Customers”, and that companies should set measurable goals for the company, executives, and employees related to this purpose. In this light, the idea that a developer’s work can be summarized as “writing code” feels almost insulting. Great software teams tend to spend the vast majority of their time figuring out what problems their users are facing, potential solutions to those problems, and the best technical approach to solving those problems. A small percentage of their time is spent actually typing code. In this environment, “their work” is not just writing code, but delighting customers.

“…we don’t want them to build a bunch of stuff that’s not in the plan…”

This one’s pretty easy to address in an agile environment. One of the simple rules of scrum is this: “if it’s not in the product backlog, we don’t work on it”. This provides transparency to the system.

Another potential concern:

“…developers will promise customers stuff that we can’t deliver…”

Sales people have been doing this for decades, so this isn’t much different <grin>. At least if developers promise something, they get to experience a direct consequence of their action, so the behavior is likely to improve.

So get out of the building, talk to customers, find out what’s driving them crazy. Scrum says that developers should spend 10% of their time on forward looking backlog refinement. What if they spent an additional 10% of their time talking to customers? Would we have a higher chance of delighting customers? It’s an interesting hypothesis. Anyone care to test it?