Name of Pattern

Pattern Context

Many teams discuss and say they want to make changes to their development process in a Scrum Retrospective, but far fewer actually make those changes.

This pattern further refines the Sprint Retrospective practice of Scrum.

The breadth of this pattern is any team that uses Scrum.

Problem

Teams discuss process changes in their Sprint Retrospectives, but often don’t follow through with those changes.

Forces

Positive Forces

Reviewing and/or discussing the status of the previous retrospective action items helps provide transparency about the adaptations being attempted and/or completed. This transparency and follow up makes it more likely that the adaptations will be completed.

Following through with changes to the development process is at the heart of what Scrum Retrospectives are for. Teams that follow through with these changes will improve their productivity in creating and delivering highly valuable products.

Negative Forces

Taking the time to track and bring the action item statuses (or discuss the statuses) in the beginning of the current retrospective takes some time out of the current retrospective.

Teams that are already excellent at following up and completing the Retrospetive action items from previous retrospectives may not get a lot of value out of expending this time.

Teams that don’t implement their Retrospective action items will miss out on the possible improvements that could be made to the team.

At first blush, following up on a plan or action items may seem like common sense, but in practice, few Scrum Teams follow up well on their Retrospective action items.

Past product development practices often supplied some sort of “process improvement discussion” meeting, but didn’t put the emphasis on actually making process changes. Many newer Scrum teams fall back into this habit of complaining but not doing anything to make changes.

Solution

The Scrum Team does a quick review of the status of the action items from the previous retrospective(s) at the beginning of the current retrospective.

As part of the review, it should be clear which items were completed and the status of any remaining open action items. The reason to review them at the beginning of the retro is so that any remaining open action items will be in the forefront of people’s thoughts.

The format and length of the review will be highly dependent on a team’s needs and how much a team already knows about the status of the previous retrospective action items. I suggest a length of between 2-15 minutes.

Quick Review

If everyone in the room knows exactly the status of each previous retro action item, then you can just make a statement like “These two items were completed, one was carried over, and one was not worked on at all.” (I generally recommend that teams focus on a small number of retro action items like 1-4).

Moderate Review

In a more moderate review, you can review each item and let team members say a few words about the state of each action item. Don’t forget the praise!

Graded Review

If you really want to inspect your improvement results, give each action item a letter grade (A, B, C, D, F, etc). You can have the group come to consensus on the grade, or you can have people write their grade on a piece of paper and then have the whole team reveal at the same time(similar to planning poker).

I’ve used this pattern on two of the teams I’ve coached and it has had success. While I haven’t gathered empirical data on it, I did notice a marked increase in completion of retrospective action items.

Variations

Review in the Sprint Review – In Jeff Sutherland’s Scrumming the Scrum pattern, which includes a similar practice of reviewing items each Sprint(he uses an impediment list instead of a retrospective action item list), he suggests presenting the results of the action item at the Sprint Review. I question that myself, because I don’t feel like the business stakeholders who represent users really care about the details of Scrum Team mechanics or Scrum Team improvements(especially when they are technical or development process oriented in nature). It also offers an opportunity for people not faimilar with intra team details a chance to give inappropriate or unhelpful feedback. On the other hand, sometimes user rep stakeholders can help resolve organizational impediments better or faster than technical folks. I suggest you decide which Scrum event is better for your team’s needs. Or, better yet, try both, then retrospect on the results!

Retrospective Backlog(aka Improvement Backlog, similar to Impediments Backlog) — Make an ordered list of outstanding action items and review the list like a backlog at each retro. Order the list by perceived value to the team and/or organization. Update the backlog each retrospective with new action items and re-order as appropriate. Take on the top couple of items each Sprint to resolve them. Consider making a separate list of blocked action items. Sometimes a list of blocked items is helpful because a blocking condition gets lifted at a later date. At that point, the blocked item can be moved to the Restrospective backlog and ordered as appropriate. Making one or both of these lists visible to outsiders may spur help from an outsider with resolving an item.

Resulting context

Teams actually improve more often and quicker due to heightened transparency on Retro action items.

Teams often get motivated by the amount of changes they’re able to make and making improvements becomes more of a habit.

Teams often have improved morale due to the empowerment they feel to self organize to make their team’s development processes smoother.

Tip: Try to estimate tasks as a team.

Don’t take this the wrong way. I’m *not* suggesting that you all sit around a table and estimate tasks like Planning Poker or anything. Besides, Planning Poker is for sizing Product Backlog Items, not Sprint tasks. What I am suggesting is that when your team does Sprint tasking, generally in the Sprint Planning Meeting, allow the entire team to see the tasks and suggest modifications. Typically, with an experienced team, I recommend the team split up into pairs to create tasks for each Product Backlog Item. I then have the team re-join later and let the entire team view all tasks and their estimates. I then encourage the team to spend a short amount of time tweaking the tasks and estimates. Don’t fall into task analysis paralysis or anything, just give some short amount of time for some high priority tweaking. Whatever you do, don’t overthink task estimates! Just put something down quickly and then retrospect on it later.

Tip: Re-tasking mid-sprint is perfectly acceptable

It is perfectly acceptable to re-task one or more tasks mid sprint. Sometimes, you’re just not able to accurately predict the tasks for your sprint. The most important thing about your Scrum board is that it accurately reflects the work remaining in the sprint, to the best of everyone’s knowledge. I recommend you do not re-task alone. The tasks were originally created as a team in the Sprint Planning Meeting, so it’s important that you don’t re-design tasks alone. Consult with at least one team member when you’re doing this. Also, inform whoever updates your Sprint burndown so that the calculations stay correct. If the re-tasking is noteworthy, take 30 seconds to increase transparency by letting the entire team know about the re-tasking activity at the Daily Scrum.

Tip: Make sure the Team fully understands all Tasks

Sometimes a small sub-portion of the Team will do the initial creation and estimation of tasks. In these cases, make sure that the Team eventually takes a broad view of the Sprint Backlog before finishing the Sprint Planning Meeting. Near the end of the meeting is a good time to have the entire team view the entire Sprint Backlog and get clarifications make tweaks. Don’t get too caught up in the clarifications, of course. Whatever you do, don’t overthink tasks! Just create simple tasks and then retrospect on them later.

Like this:

Executive Summary

In this article, I discuss the role of those outside of the Scrum Team. This includes managers, stakeholders, and any other member of the organization that the Scrum Team works for. I look to the Scrum Guide first, and then discuss some other ideas not specifically from the Scrum Guide. In short, the role of those outside of the Scrum Team is to:

Collaborate with the Scrum Team on Release Planning

Collaborate with the Scrum Team in Sprint Reviews

Influence, but not contradict, the work priorities as decided by the Product Owner

Some other thoughts of mine on the role of those outside of the Scrum Team

As much as possible, those outside of the Scrum Team should try to work as Servant Leaders to the Scrum Team, by removing impediments. Every impediment removed is one more chance for the Scrum Team to succeed by delivering value to the organization as a whole.

As much as possible, those outside of the Scrum Team should work very hard not to interfere with the Scrum process implementation as executed by the Scrum Team.

Stakeholders of the system under development should take every opportunity to guide the product’s development by collaborating with the Scrum Team during Release Planning and Sprint Reviews. These two activities, in particular, thrive on good customer/stakeholder feedback, so the outputs to those activities are only as good as the feedback that is given as input.

Like this:

Short Story:

When teams struggle with Scrum, it is my strong opinion that they should look *first* to the Scrum Guide for guidance.
(Or *look back* to the Scrum Guide, if they are an experienced team)

Long story:

A more complete way of saying this is:
When teams struggle(whether they be beginner or experienced), it is my strong opinion that they should look *first* to the Scrum Guide, and secondarily to other resources (books, articles, online, other professionals) for help. In fact, read and learn as much as you can from the Scrum Guide and the secondary resources. So long as those other resources don’t contradict the Scrum Guide, then it’s probably ok to try what they suggest. If those other resources do contradict the Scrum Guide, then think long and hard before deviating.

I have observed the following Anti-Patterns with respect to Scrum implementation.

Faux Scrum: Disinformed or Misinformed
1. Someone advocates a practice that is not consistent with the Scrum Guide.
2. The team struggles with that “something, ” often times because the “something” is not really Scrum at all, but some practice that someone inaccurately said was Scrum.
3. Rinse and Repeat until either:
a) “Scrum” is a dirty word in your organization, or b) your organization settles for mediocrity, or c) you decide to move on to some other process, or d) until someone figures out what you are doing is way out of line with the Scrum Guide vision, and tries to help you get back to basics.

Faux Scrum: Give up quickly and Deviate from the Scrum Guide
1. A team struggles mildly with implementing some practice described in the Scrum Guide.
2. Rather than retrospect and improve their implementation of the practice as the Scrum Guide would suggest, they choose a different practice that deviates from the Scrum Guide, usually with negative consequences that that team may or may not have the ability to immediately see.
3. See step 3 above.

Faux Scrum: Pretend you’re doing Scrum
1. Pretend to be doing Scrum, but instead use a bunch of your existing practices instead of what the Scrum Guide suggests. “Hey look, Mom! We’re Agile!”
2. Rename a lot of your old practices, artifacts, and roles with Scrum terms. Proceed as usual with the status quo and tell everyone in your company how Agile or how Scrummy you are.
3. See step 3 above.
(Ken Schwaber calls this the “Methodology Facade Pattern”)

Faux Scrum: Selective Scrum
1. Like you did successfully with WaterRUP processes, selectively pick a small number of Scrum practices and implement those only.
2. Enjoy the new practices, but be sure you stop progressing towards the Scrum Guide vision either because you get too complacent or too busy.
3. see step 3 above

The Power of Positive Thinking
I know what you’re thinking. Man, this guy is negative! If you spoke to people in my personal or work life, I think they would tell you that I’m generally a very positive person. I’m even hilarious at times, but that’s hard to convey in prose about intellectual topics. I think, though, that they would also tell you I’m a very detailed person, and that I’m honest and direct about serious subjects.

So, rather than call everyone “Chickens” and “Scrumbuts” and “Faux Scrumites”, what I do instead is I advocate a positive strategy.That positive strategy is : When deciding how to proceed with Scrum, look to the Scrum Guide *first*.

If you look at my blog and web site, I generally give positive advice, but I also don’t shy away from Worst Practices, Anti-Patterns, Bad Smells, and Traps. Any good tester tests happy, sad, and bad paths, usually with particular attention to the sad and bad paths. I do the same. I also make sure that I propose solutions to all of these Worst Practices, Anti-Patterns, Bad Smells, and Traps. I do want to help, but sometimes people are not Scrum knowledgeable enough to recognize the bad practices.

Sometimes, to convince people to get back to basics, I have to point out where they’ve deviated from the Scrum Guide. This usually involves quoting the Scrum Guide. Yet other times, to further convince people to get back to basics, I have to express some of the possible advantages and disadvantages of their current strategy. That’s part of being a Scrum Coach and change agent, and comes with a certain amount of resistance. I’m ok with that. The reason I’m ok with that resistance is that I do it because I passionately and honestly believe it’s the right thing to do.

Two schools of thought: More updating or more granular

There are generally two main schools of thought about how to task out a sprint in hours. One thought is to create tasks that are a bit larger in size, but to re-estimate each task that is in progress at some point of every day, usually whenever the burndown is updated. The Scrum Guide is pretty specific on this — the task estimates must be updated daily so that the burndown reflects a very good estimate(to the team’s best knowledge) of the amount of work remaining in a sprint. In addition, according to the Scrum Guide, 1 day is the largest a task can be anyway.

Another school of thought is to make lots of tasks, and make them small, such that the need for the daily ritual to update each “in progress” task’s remaining time is really not necessary. Using this method, the burndown will still reflect very accurately the amount of work remaining in the sprint. For this strategy to work, though, the tasks need to be preferrably closer to a half day or less in size. I strongly prefer this method, because having to update each “in progress” task every day, especially when the tasks are larger, is a logistics nightmare and not terribly enjoyable(not to mention reminiscent of WaterRUP). Besides, smaller tasks reduce bottelnecks, increase transparency, and generally allow teams to optimize effiiciency better, as we’ll see below.

Granular is good!

*Development Managers, Project Managers and Team Leads: Don’t be afraid to be very detailed at the Sprint tasking level. Read this section verbatim!*
For the sake of transparency and many reasons that will become apparent below, granular tasks are good. By granular, we mean prefering tasks that are 1-4 hours of ideal time per person involved in the hopefully small, atomic, and discreet task. Many experienced Project Managers and Team Leads seem to fear this type of granularity. I think this fear is a holdover from traditional project management and WaterRUP techniques, and the use of planning tools like Microsoft Project. In traditional project management, making tasks too granular has disastrous consequences, and requires a huge amount of tedious maintenance to keep the project plan leveled and up to date. It doesn’t help that traditional projects would last for months or years, thus making granularity exponentially disastrous.

*But wait! Stop the presses! Take off those pukey colored “WaterRUP” glasses and let’s enjoy the Agile view for a minute.*

Agile processes like Scrum thrive on short cycles. The Sprint Backlog is the project plan for a single Sprint. Sprints in Scrum are limited to 4 weeks in length, and most teams choose a Sprint length of 2 weeks. Because of this, the Sprint Backlog’s project plan duration is literally *never* more than 4 weeks in length, and usually not more than 2 weeks in length.

The Sprint Backlog is never created in advance. That’s right, I said NEVER! You will almost never have to do any significantly sized re-working of the project plan because it is created just in time and your crystal ball only has to look 1-4 weeks into the future. So, the entire lifetime of this Sprint Backlog is never more than 4 weeks.

The Sprint Backlog is discarded after the Sprint. Yes, that’s right, I said discarded. You are never again chained to a project plan that never ends. You can literally tear up this project plan after 1-4 weeks!

More granular tasks leads to higher transparency, making it easy for you to know exactly what is going on within the team.

More granular tasks leads to a more accurate prediction of work remaining (aka The Sprint Burndown)

More granular tasks leads to a better comparison with the capacity burndown(aka “the ideal burndown line’). As such, timeline risks are almost immediately identified in real time!

Tasks are created and maintained by the self organizing development team, so no secretarial duties specifically for Project Manager types, like having to futz with MS Project or some other project data entry tool.

For the rest of the tips, I will assume that you’re going the more granular task route, but many of the concepts will translate to using larger tasks as well.