Michael James’ Checklist:

• http://blogs.collab.net/agile/2007/08/13/a-scrummasters-checklist/?q=blog/michaeljames/a_scrummasters_checklist

Mike Beedle’s List:

• http://www.enterprisescrum.com/blog/2011/12/20/responsibilities-of-the-scrummaster.html

Please inform me of any similar lists you’ve found and I’ll add them to my collection.

http://properosolutions.com/2011/10/the-secrets-of-successful-test-automation/

Lisa, the original presenter, is also co-author of Agile Testing. She is super sharp when it comes to Agile testing and Agile automation. I observed one of her training classes when I was at another client. Her book is great, though I found it a little overwhelming at times. Mostly just due to it’s volume and advanced level. (Also partly due to my background being more in development than testing). I highly recommend you subscribe to her blog.

Brad, the ‘blog summarizer’, is someone I’ve worked with in the Agile community. He is a leader for AgileDenver, and he also was a leader in organizing an outstanding conference, MileHighAgile. I highly recommend you subscribe to his blog , too.

I hope you noticed that I listed a couple of people I know and greatly respect on Agile and Scrum. The number of people on “that list” is pretty darned small.

• Best Practice -a practice that is good in almost all contexts and almost all team situations.
  • more details…

Many teams talk a good game on making changes to their development process, but fewer actually make those changes. Therefore, it is a Scrum Best Practice to make Retrospective action items highly visible to the team, usually on or very near the Scrum Board.

The visibility technique employed will be highly dependent on the team. Consider some of the following methods, or come up with your own!

• List them in big letters on a Scrum Board
• Create Sprint Backlog Tasks for action items and make sure they get to “done”.
• Do this: Best Practice – Review the Action Items from the Previous Retro in the Current Retro
• On certain days (Like Mon/Wed/Fri, Tue/Thurs, even, odd, every day, etc) in the Daily Scrum, have a team member pick a retro action item to talk about and have them talk for 30-60 seconds(time-box) about the action item. They can talk about the state of the item(announce completion!), why the item is important, give the person who came up with it or completed it praise, or even something like what life will be like once that action item is completed.
• On random days, offer a prize for anyone who can list a retrospective action item that is supposed to be completed in the current sprint. The prize can be very small or token, maybe as simple as candy or another desirable treat.

• Best Practice -a practice that is good in almost all contexts and almost all team situations.
  • more details…

Name of Pattern

• Retrospective Follow Up

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.

However, I’ve encountered certain situations where it doesn’t seem like Scrum works well. They all pretty much boil down to two generic cases:

• Applying Scrum to a problem domain it was not designed for, or
• Applying Scrum where people or processes actively or passively work against Scrum principles.

IMO, Scrum may not be the best fit for:

1. Companies who will actively or passively work against Scrum and its major principles.
   • This includes companies that do Faux Scrum.
   • If the Company doesn’t care what process is used at the team level, and won’t constantly act against Scrum, then Scrum is fine at the team level.
2. Companies who are expecting a lot of benefits from Scrum but cannot commit to doing Scrum in a good faith, holistic, way.
   • How does one do Scrum in a holistic way? Look to the Scrum Guide first
3. Companies that like to matrix numerous people into numerous projects.
   • Matrixing at the Product Owner or ScrumMaster level *may* be ok(but probably not optimum) if the people are experienced/highly knowledgeable in those roles.
4. Teams who cannot commit to a week of fairly fixed scope (say, where < ~70-80% of the scope is fixed for a week).
   • Examples of teams that sometimes cannot hold to this are generally interrupt driven type organizations, like network support, production support, software operation support, etc. A Kanban type of approach can be considered with such highly variable scope, but I’m not a fan of the Kanban movement yet because it is still incubating IMO.
   • Be careful on this one.  If your team experiences high scope churn, it may just be a really bad dysfunction that needs rectifying.  Look closely before discarding Scrum here.
5. Teams where members and/or leaders will actively or passively work against Scrum and its major principles.
   • This includes companies that do Faux Scrum.
   • Stealth approaches are fine, but if there isn’t enough consensus to work within the Scrum framework(especially from team leaders), then results will probably be mediocre.
   • I have seen some team leads(or functional managers) who embrace the principle of self organization (always to a point, especially if the team lead has more command and control responsibility from above), and I have seen team leads who just can’t let go of the authority. In cases where a team leader cannot let go of the authority, Scrum may be a disaster, especially for those advocating for it. If you’re in one of these situations and you really love Scrum, find a new team or organization to work for that truly embraces Scrum.
6. Something other than software development.
   • It’s my personal view that true Scrum is for software development. One can adapt Scrum to other domains, but then it’s not really Scrum any more. One can certainly use “adapted pseudo Scrum” effectively, but that’s only if the person guiding the adaptations is a Scrum and/or process expert. I strongly believe that many Scrum concepts can be “lifted out” and used very successfully elsewhere — but again, that’s not really Scrum any more IMO.

Again, please don’t take this the wrong way and use these scenarios as an excuse to “give up on Scrum.” Scrum is about the “art of the possible,” and the only time it doesn’t work is when it is not ‘possible.’ I believe the situations above to be when Scrum *may* not be possible (or at least very difficult). In pretty much any other situations than the ones described above, I will defend Scrum heavily as possible and potentially highly beneficial.

Below are some examples of interesting situations where I didn’t think Scrum was the best fit.

Example #1

I had a company call me once for advice on Scrum. In short, they were doing the typical consulting firm thing where everyone works on ~3+ projects at once, which meant ~3+ different teams for each team member. I told her they either need to re-org into teams that work as teams, or forget about Scrum and find something else. I love Scrum, but matrix hell is Scrumbut City and it won’t work.

Example #2

(in this one I didn’t recommend against Scrum per se)

I interviewed to be a Scrum Coach(as a consultant) with a company. They had a couple of major Scrumbuts that they were unwilling to change, yet they expected to obtain significant productivity gains from using Scrum and wanted me to make that happen. An hour or so after the interview, I called the person who set up the interview and I told them I didn’t believe they would reap the benefits they sought because they weren’t really willing to embrace Scrum. As such, since I didn’t think it would be a successful engagement, I politely declined.

• Best Practice -a practice that is good in almost all contexts and almost all team situations.
  • more details…

Break through the B-O-R-E-D-O-M!
Retrospectives can get boring, and when they get boring, the effectiveness of them falls off dramatically. To help prevent this boredom factor, change up your retrospective format. There are lots of websites and even a few books that discuss numerous retrospective formats. You don’t even have to follow those formats down to the last detail — change that up too!

Rule of Thumb
My rule of thumb is that a team should never do the same retrospective format more than 3 times in a row. Either change a major piece of the format, or try a new one altogether. Not all formats will work well for all teams, but often you really don’t know how well one will work out unless you try it.

Some Boundaries
All formats should respect a few Scrum boundaries, so be sure that the your proposed format roughly adheres to the following:

• Discuss the major things that went well in the last Sprint.
• Discuss the major things that could potentially be improved in the next Sprint.
  • Improvements should not be changes to the Scrum Framework, but should be changes *within* the Scrum Framework.
  • Improvements should have the goal of making the Scrum Team’s work more effective and/or more enjoyable.
• Create a plan for implementing the improvements in the next Sprint.

The retrospective can be very interactive, casual, and creative, and still cover the above main points.

What are your tips for retrospectives?

.

Advice Classifications

My hope is that the consumers of my advice will know just how broadly, in my opinion, that the advice applies to problem spaces.

Answer:

In My Coaching Experiences…

Here is what, IMO, the best solutions look like, based solely on my coaching experiences:

1. If it is at all possible, add the item to the backlog and start on it in the next sprint. If not, go to step 2.
2. Don’t reserve time or “points” out of the sprint for prod support time or issues ahead of time.
3. Any Sprint task that takes less than an hour or so in a day is not really worth tracking or worry about unless there is a risk that the team will forget about that task. As such, I coach teams to apply this to production support time too. One might call this “immaterial tasks” or “immaterial time.” So, if prod support takes immaterial time, don’t worry about tracking or dealing with it — just do it!
4. The PO must approve all scope in the sprint, including material production support time.
5. If the production support time becomes material, then track the item as a new backlog item or a new task or tasks. If this higher priority prod support time affects the amount of scope that the Dev team originally forecast for the sprint, then the PO and Dev Team will negotiate which item(s) gets dropped.
6. Restrospect on these occurrences, then inspect and adapt.

Scrum Guide relevance…

Scrum is geared towards product development, not product maintenance or support. It has never been clear to me how prod support fits into Scrum by reading the Scrum Guide — maybe it shouldn’t fit.

On the one hand, because the Scrum Guide never addresses it directly, one can assume that is up to the team to implement a solution. On the other hand, many production support issues seem to conflict with many Scrum principles and rules such as the rule that scope changes that affect the Sprint Goal are not allowed. Then there is the rule about canceling a Sprint, but surely you can’t do that every time an important production support issue comes up.

One last consideration is that the SM serves the Dev Team by:

• “Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.”

In the past, I have taken this as a license to coach teams to a solution like the above — and then coach them to inspect and adapt.

A lot of interruptions

If you have a Scrum Team that gets interrupted a lot, you need to think long and hard as to why the team is getting interrupted.  Do a root cause analysis and come up with possible new things to try. Sometimes the answer to the problem is software quality.  If your team is essentially stuck with having to be interrupted regularly where the interruptions take up a significant part of the Sprint(say 20-40%), then you should consider the Illegitimus Non Interruptus pattern.  Sometimes the  answer is to not use Scrum.  If your team is more of an operations or support team that doesn’t do very much new product development, then maybe Scrum is not the best process framework for what you’re doing.  In that scenario, you might consider alternatives like Kanban.  As always, inspect and adapt!

How do you handle production support and Scrum?  What tips and hints do you have on how to handle this?

Click on the comments and let us all know as it’s not an easy issue to deal with!

.

Scrum Master

The role as defined in the Scrum Guide. In summary, the Scrum Master:

• Acts as a servant leader to the Scrum Team and Organization, helping them to adopt and get better at Scrum.
• Ensures impediments to Scrum Team delivery of high value software are removed.
• Ensures that the Scrum Team adheres to the Scrum principles, values, roles, rules, and practices.
• Helps Product Owners and Development Team members play their Scrum role, but otherwise does not in any way control or strongly influence how the software is developed and delivered.

A Scrum Master brings value to an organization in these ways:

• A good Scrum Master helps the org adopt and progress towards good Scrum in a feasible way.
• A good Scrum Master helps the Scrum Team deliver higher quality, higher value software faster, by maximizing the benefits received from Scrum.

Scrum Coach

One who can effectively teach and coach all roles as defined in the Scrum Guide(SM, PO, Dev, org). Ideally, IMO, the Scrum Coach will have actual past experience playing all three of the main roles(or very similar roles) somewhere in their background. Another very important trait of a Scrum Coach is experience coaching in a variety of organizational settings. In this way, the Scrum Coach brings best practices about Scrum adoption to the organization. No certification is required to do this. I could get into the specifics about what I think about the SA Scrum Coach certification (advantages and disadvantages), but there are a lot of Scrum Alliance Certified Scrum Coaches out there and I’m not sure I have the time to take them all on at once. Maybe some day. In my ideal world, a Scrum Coach is responsible for taking the Scrum Maturity of one or more Scrum teams to a significantly higher level.

A Scrum Coach brings value to an organization in these ways:

• Utilizing broader experiences and adoption best practices, the Scrum Coach helps the organization and (often multiple) Scrum Teams adopt and progress towards good Scrum in a feasible way.
• A Scrum Coach progresses an organization’s Scrum Maturity much faster and more efficiently than someone with more limited experiences or someone who is playing solely a Scrum Master role.
• Helps (often multiple) Scrum Teams deliver higher quality, higher value software faster, by maximizing the benefits received from Scrum.

What do you think?  Are there other key differences between the roles?  If so, click on the “Comments” link and post your thoughts.

In my previous article, I give an overview of some of the interesting changes incorporated into the 2011 Scrum Guide. One of the most interesting changes in my view is the inclusion of Backlog Grooming as a required practice. In my Scrum coaching experiences, the one practice that seems to help beginner Scrum teams the most is backlog grooming. In some cases, the practice itself makes many PO related obstacles highly transparent, but transparency is what we want!

Backlog Grooming: The Red Headed Step-Practice.

I think that many beginner Scrum teams have trouble deciding on how best to transition to Scrum. They focus so much on the major practices (Product Backlog, Planning, Review, Retrospective), that they don’t realize that backlog grooming can ease some serious Sprint pain. This idea that the Sprint Planning Meeting is the first time we hear about all new backlog items is absolute nonsense, but that’s how the pre 2011 Scrum Guide read to a lot of people. Will there be late breaking backlog items that might be presented for the first time at the planning meeting? Yes, but it should be rare to very rare.

Third Time’s the charm…

I’ve found that most teams seem to have the highest productivity on implementing a backlog item when they’ve had a chance to discuss the item 3 times, with the 3rd time usually being the Sprint Planning Meeting for the Sprint in which it will be implemented. Each time a backlog item is discussed(with the whole Scrum team present), it is decomposed a little further and open questions and risks are identified. In between these three discussions, people should take action items to answer these questions and mitigate the risks. These action items are ones that often take days in duration to answer, for whatever reason (answers from stakeholders, technical deep thought and investigation, etc), but don’t take a lot of effort for each action item. Throwing all of these action items into a 2-4 week sprint means you’re putting these long duration tasks onto the critical path, and that’s just not productive.

My Coaching Style for New Teams

When I coach a team that is just beginning Scrum, I actually start with backlog grooming first. I usually pick a point on the horizon 2-3 weeks out and say: “Sprint 1 will start on date X, and between now and then, I want you to continue working how you have been working, except that we’ll have a few training sessions between now and Sprint 1 so that we can hit the ground running(or “Sprinting,” if you prefer). Much of the time in those training sessions is focused on good backlog grooming techniques (and usually User Stories and Story Testing). It all starts with requirements!

Experienced Scrum Teams are Not Immune

Other non beginner Scrum teams also never seem to get to the point where they do backlog grooming well. I think many Scrum teams plateau when it comes to implementing Scrum, and this is really unfortunate. As Jeff Sutherland suggests in the Enhanced Nokia Test (aka “The ScrumBut Test”), the huge productivity gains for Scrum teams are in the last mile of implementing Scrum. If a team never gets to that last mile, then the high productivity promised by Scrum is never achieved. If your team wants to get highly productive, then your team needs to get really good at backlog grooming.

In My Ideal World…

In my ideal world, a team will first see a backlog item at a high level in a Release or other high level planning meeting. They will then dive deep into the item during a backlog grooming session near the beginning of the Sprint before its most likely implementation, identifying requirement and technical risks, logic questions, and other things that get in the way of fully decomposing the item into acceptance (or story) tests. Then, the item might be lightly touched on outside the grooming when unknowns become known, or maybe again in a grooming session a few days before the next Sprint. Then, at the Sprint Planning meeting, there are only very minor unknowns about the item, and the team is well versed on what is trying to be accomplished by the item. Knowing what work will need to be done for the item means the team can better plan their work for the Sprint. They can front load risks, parallelize efforts (automating the acceptance tests is a good parallel effort), and visualize the critical path for this and other items.

Where to Find Out More

I’ve written a series of articles on Backlog Grooming. <shameless plug> I haven’t updated them for the 2011 Scrum Guide yet, but nothing much about the 2011 Scrum Guide changed the practice itself, so probably 97+% of the material is still applicable.

For my articles on Backlog Grooming, see:

• Why do Product Backlog Grooming?
• What does Product Backlog Grooming Look Like?
• Tips for Effective Backlog Grooming