Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

Posted on February 4, 2013 by charlesbradley

Last week I was a panelist at the Agile Denver meeting, where the title of the panel was Kanban vs. Scrum! The Big Smackdown!

If you click through the link, you’ll notice that the title was misleading, on purpose, as is the title of this article(“Kanban vs. Scrum…”).  However, I want to catch the attention of those who think that this is even a valid question or consideration.  The title also speaks to a common problem in the industry that has been around for several years, and won’t seem to go away.

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your team’s software development process is a mistake.

1.  You are applying Kanban to the incorrect context.

Would you use a hammer to insert a screw in a wall?  You can, but you’ll probably damage your wall in the process, and the same is true of Kanban as a software development approach.  David Anderson, the creator of The Kanban Method, has apparently said this over and over again since 2005, but no one seems to listen.

Don’t take my word for it, listen to David:

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!” — David Anderson

“There is no kanban process for software development. At least I am not aware of one. I have never published one.”  — David Anderson

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.” — David Anderson*

(*The first two came from the “over and over..” link above.  The last quote was sent to me via email from someone at David’s company.  I think they just pasted in something David had already written)

I should also mention that others have mentioned to me that David talks out of both sides of his mouth about Kanban, Agile, and software development, perhaps trying to capitalize on the fame and success of Agile software development.  That may be true, but it may also be true that David has been saying all of these things for years and no one is paying attention to what he says, which is unfortunate.

2.  Kanban is modeled more after the assembly line and manufacturing.  Scrum is modeled more after creative product design.

Which do you think more closely resembles software development?  Laverne and Shirley on the assembly line at the Shotz Brewery? Or the group of NASA engineers on the ground who saved the lives of the Apollo 13 astronauts by coming up with a creative solution to a problem within a time-box?  If you think software rolls off of an assembly line, then I think that it is unfortunate that you’ve never worked in a creative software development environment — it’s AWESOME!

Maybe my Laverne and Shirley reference is oversimplified.  The reason to use Scrum instead of Kanban for software development delves down into process control theory, and the difference between a “defined process” and an “empirical process.”  In short, a defined process works better when the inputs and outputs to the process are well known and repeatable (like a manufacturing line).  An empirical process works better when the inputs and outputs to the process are less known and very difficult to repeat.  No two software features are alike.  This is why it’s darned near impossible to measure software productivity directly, even though some naive “bean counters” still try to.  Like the stock market, no one metric will predict it accurately, but a range of indicators can help predict it more accurately.  So, in summary, Scrum is based on empirical processes like product design.

One of the very key parts of empirical processes is the characteristic of inspecting and adapting the product.  Think of yourself making a pot of soup from scratch, without a recipe.  Think about all of the “taste-tweak ingredients-taste” experiments(feedback loops) you would need to get a pot of soup that tastes good.

Scrum has the frequent feedback loops built in, for a variety of audiences(Dev Team, Product Owner, Stakeholders, Users) , and for a variety of topics(process-Sprint Retro, product-Ordered Product Backlog, product-Sprint Review, product-Valuable/Releasable Increments).  Kanban has no such built in loops, but again, that’s because it wasn’t designed for software development!

3.  From a Complexity Science view, Kanban is for ‘complicated’ work while Scrum is for “complex” work.

I know the Kanban folks don’t like hearing this, but I think Ken Schwaber was right when he said this, and I think history will prove him right about Kanban as it was described in David Anderson’s book.  In short, the Cynefin model defines 5 domains, of which 2 of them are “complicated” and “complex” work.

‘Complicated’ work is best solved via ‘good practice’ and ‘experts’ who can find ’cause and effect’ fairly easily. When I think of ‘complicated’ work, I think of an the IT support person who sets up your computer or trouble shoots it.  Yes, you need an expert to solve these problems, and the vast majority of the time, the steps to solve these kinds of problems are fairly consistent and repeatable.  They are not exactly repeatable, just mostly repeatable.   If the steps were exactly repeatable then they would fall into the ‘Simple’ domain of Cynefin.

‘Complex’ work is best solved via ‘safe to fail experiments’ and one can only ascertain cause and effect after the fact.  Each Sprint in Scrum is a ‘safe to fail’ experiment because, while the Sprint increment is always releasable, the business side of the house makes the decision on whether it is safe/valuable to release it or not.  In the case of an increment that is un-safe, the team course corrects and comes back with an increment the next sprint that is hopefully safe or more-safe.  These safe to fail experiments can be repeated over and over again until it’s time to release the increment.

Applying Kanban Correctly

Having said all of the above, there IS a time and place for Kanban — a correct context, if you will.  If you’ve been reading closely, that context is as a change management process, which is ‘complicated’ work, and requires that there be already existing processes in place.  So, if your software team is doing XP, Scrum, Crystal, Waterfall, RUP, DSDM, FDD, etc, then you can layer Kanban on top of it to help find bottlenecks and waste.  Also, for all of those teams out there that don’t use a software development process(framework, approach, etc) that is named in the industry, you’re probably doing cowboy coding, ad-hoc, or command and control project management — none of which is a software development process either.  So, layering Kanban on top of crap will still yield crap.

For those that want to apply Kanban at the enterprise level to monitor the flow of work through their Scrum teams (Or XP, Crystal, etc), or want to use it for IT support or Dev Ops, I say have at it and I hope it helps you.  I imagine just visualizing your workflow alone will help in those contexts.  I myself have recommended and coached Kanban for a couple of teams — but only because those teams exhibited the right context for Kanban to be successful.

Bottom Line

Having said all of this, just visualizing your workflow and the other Kanban principles is not enough for software development.  Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.  Scrum does address these areas, as I have shown above.  But hey, let’s not forget, the Kanban Method is “not a way of making software or running projects that make software.”  Would you criticize a hammer for not doing a good job of being able to insert a screw into a wall?

Related Articles

ScrumCrazy.com update:

  • Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
  • Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.   Contact us for more info

Filed under: Agile, Bad Smells, Kanban, Organizational Change, Scrum, Scrum Adoption, ScrumMaster Tips, The Retrospective, The Sprint Review | 42 Comments »

Towards a Catalog of Scrum Patterns

Posted on December 6, 2012 by charlesbradley

I’ve been thinking a lot lately about Scrum patterns.  To that end, I’ve drafted a conceptual model, which is depicted in the below image.  (You may want to click the image twice to see a bigger view of it)

ScrumPatternsOverviewOnePage

“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.”  In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required.  In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team.  So, this is what inspired me to use the term “Scrum Technique Pattern.”  A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide.  Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework.  Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.

“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide.  These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.

I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context.  For instance, we might start out with a Scrum Starter Kit that includes things like:

  • Holding a Release Planning meeting every 2-3 months (OSP)
  • 2 Week Sprints (STP)
  • Using Story Points to estimate Product Backlog Items(STP)
  • Using Ideal Hours to estimate Sprint Backlog plan items(STP)
  • Doing a typical burndown chart to sum the remaining work for the sprint(STP)
  • Representing Undone Work(OSP)
  • Doing the typical “round robin” style of the Daily Scrum(STP)
  • Doing a fairly typical “Plus-Delta” retrospective analysis(STP)

Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum.  Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.

Who writes these patterns?  Where do they come from?

In a word, anywhere.  I’ve seen dozens of them on the internet and in books.  I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due).  I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum.  Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.

I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.

Filed under: Agile, Organizational Change, Release Planning, Scrum, Scrum Adoption, Scrum Strategies, ScrumMaster Tips, Story Points, The Daily Scrum, The Retrospective, The Sprint Review, User Stories | 6 Comments »

My Preferred Agile, Scrum, and XP Resources

Posted on June 4, 2012 by charlesbradley

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.

Scrum

  1. The Scrum Guide (Must read for all)
  2. Deemer, et al. “The Scrum Primer”
  3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
  4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
  7. Derby/Larsen’s _Agile Retrospectives_

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Agile/XP Testing

  1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  2. Cripin’s “Using the Agile Testing Quadrants”
  3. Crispin/Gregory’s _Agile Testing_
  4. Crispin/House’s _Testing Extreme Programming_
  5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  6. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. My “User Story Basics” article and all of the links at the bottom of that article
  2. Cohn’s _User Stories Applied_
  3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  4. Lawrence’s “Patterns for Splitting User Stories”

Special Agile Topics (if applicable)

  1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
  2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)

Filed under: Organizational Change, Product Backlog, Product Backlog Grooming, Product Owner Tips, Release Planning, Scrum, Scrum Adoption, Scrum Strategies, ScrumMaster Tips, Sprint Backlog, Sprint Planning, Story Points, The Daily Scrum, The Retrospective, The Scrum Artifacts, The Sprint Review, The Sprint Time-boxes, User Stories | 8 Comments »

One Way to Handle Bugs and Production Support in Scrum

Posted on April 18, 2012 by charlesbradley

This article has been updated and republished here.

Filed under: Bad Smells, Organizational Change, Product Backlog, Scrum, ScrumMaster Tips, Sprint Backlog, Sprint Planning, The Daily Scrum, The Retrospective, User Stories | Leave a comment »

Best Practice – Minimize Manager input in Retrospectives

Posted on February 29, 2012 by charlesbradley

One of Scrum’s main tenants is about self organization. Self organization is difficult enough to achieve on its own, especially with a new Scrum team or a team who has members who are new to each other on it. In the context of this article, when I say “Manager”, I mean someone who has a large amount of input in determining the company advancement (performance reviews, raises, promotions, etc) of any individual on the Scrum Team. It could be someone a team member reports to, or it could even just be a supervisor or team lead. Sometimes a Manager plays a Scrum role like Product Owner or Scrum Master. I’m *especially* talking about those managers. Those managers should not attend the retro, or at the very worst case, should attend only a minor part of the retro(See “Strategies” below).

It should be obvious to Managers (though often it is not), that honest genuine feedback about how to work better as a team is very hard to get with a Manager in the room. Every time a person opens their mouth, they are taking a political risk if their manager is there, and that is not a safe environment for true collaboration and innovation. Managers, if you don’t believe me, try the strategies below for 3 sprints, and judge the results for yourself. You, as a manager, have every right to ask the team, one day after the retrospective is over, for their plan of action on improvements. I say one day after because I’d strongly prefer that you not come into the room where the retrospective is being held once it is over. Often times there are things on whiteboards that you may or may not understand, and again, that becomes unsafe.

Strategies

  • Appoint a Facilitator
    • If a Manager does not fulfill a Scrum role, then the team should appoint a facilitator, preferably one totally independent of the team. Good candidates for this are Members of other teams with good facilitation skills and/or Scrum Masters from other teams. As a last resort, if that’s not possible, then appoint someone on the team who would be a good “neutral” facilitator. It’s ok if that team member also participates in the retro, but you can leave that decision up to them. Have the team prepare any specific feedback that they have that involves the Manager in their private retrospective, and present that feedback to the manager as a team. (Remember that they may have no specific feedback for the Manager, but often they will ask the Manager’s help in implementing Retrospective Action Items.)
  • Part-Time Retrospecter
    • In the case where a Manager(or team lead) plays one of the Scrum roles (PO, SM, or developer), have the team, as part of their retro without the Manager, decide which topics will be discussed with the Manager. Any topic that is not chosen for discussion is not discussed with the Manager. In particular, any feedback the team has for the Manager in their Scrum role, have the team present that as a unified team rather than individuals. Also allow the Manager to raise their own independent topics, of course. If the Manager strays into one of the topics that the team has not chosen to discuss, then inform the manager of the outcome of the team discussion.

Excluding the Manager from the Retrospective is not an attempt to usurp the Manager’s authority or anything like that. It is to create the safety and experimentation that is required for great innovations to occur. The Manager still has a very important role to play — see The role of Managers in Scrum .

Related advice

Related articles

Filed under: Bad Smells, Organizational Change, Scrum, ScrumMaster Tips, The Retrospective, Transparency | Leave a comment »

Scrum Pattern – Plus Delta Hash(PDH) Retrospective

Posted on February 28, 2012 by charlesbradley

Summary

The PDH retrospective is a retrospective format that is very efficient and fairly simple. Teams quickly generate discussion topics(Transparency) by listing the things that went well(plusses) and the things that should change(deltas) to make the team better in the upcoming Sprint. The team then has a chance to quickly vote on the discussion topics to help prioritize and order the discussions. With the discussion agenda quickly set, the team then sets about discussing the most important topics(Inspection) and develops action items(Adaptation) that allow the team to improve its Scrum implementation.

Possible Contexts

  • A team needs or wants a retrospective format that is very simple and/or efficient.
  • A team that has a very limited amount of time to execute a retrospective.
    • I personally encourage teams to use the entire Scrum time-box so long as the team thinks it is continuing to have valuable discussions. Having *retrospectives that are too short* is an anti-pattern.
      • I encourage brand new Scrum Teams to use twice the time-box for the first 3 retrospectives so that the team achieves a culture of improvement and self organization. Don’t forget the definition of “time-box,” though — your meeting doesn’t *have* to take 3 hours — that’s just the max!
  • A team that is of any size, but this pattern is very efficient for large teams.
  • A team that prefers discussion and solution seeking over free form discussion.

Situations where this pattern might not be a good fit

  • Teams that have done this retrospective format too many times and are bored with it.
  • Teams that do not have the needed supplies or tools to execute this format.
  • Teams where multiple members are working remotely (but see Variations section for a possible solution)

Steps

(This is probably obvious, but the number of votes and time-boxes can and should be adjusted to the team size, time allowed, etc)

  1. Review the Previous Retro Action Items
  2. Generate Ideas about what went well, and what changes to make.Have each team member stand in front of a whiteboard (or large post it note) and list:
    • At least 2-3 Plusses
      • Things they liked about the current Sprint.
    • At least 2-3 Deltas
      • Things they would like to see change.
    • Time-box this to a fairly short period of time (5-15 minutes). Extend the time period in small increments if people need more time. During the time-box, remind peoiple that that they are encouraged to put more than the minimum — anything that’s on their mind. These items will become the discussion topics. If the need arises (and I’ve found that it usually doesn’t), discourage people from looking at others’ lists until they are done. As much as possible, we want independent topic generation.
  3. Vote on the ideas to discuss and/or change.Hash Voting:
    • Now tell the team that they have 10 votes (you can adjust this of course, but it should be 5 at least) for Plusses and 10 votes for Deltas. Tell them to go around the room and put hash marks as their votes by topics they either a) want the team to discuss and/or b) that they agree with. They can place one vote on each topic or all of their votes on one topic. If they have questions about what something means, tell them to ask the author. Encourage them not to have the actual discussions yet, just to seek clarification of what the author meant by the topic. If they find similar topics and want to group them together as one topic, tell them to self organize to do that. Time-box this exercise to a fairly short period of time (5-10 minutes), and extend in very small increments if people need more time to vote or clarify/consoidate topics. Ideally, we really want to get people’s first instincts, so don’t allow too much time.
  4. Count and rank the discussion topics. Count the votes and rank the topics(count and rank Plusses and Deltas separately) with the most votes(1, 2, 3, 4, 5, etc). This will become the “ordered discussion backlog”.
  5. Discussion
    • Discuss Plusses
      • This usually takes very little time, but it is a chance to give each other attaboys and “I liked that too.” It also gives the team to reflect on the things that are going well, as a reminder to continue to do those things. You usually don’t need but about 5-10 minutes of discussion for those.
    • Discuss Deltas
      • Discuss the top ranked deltas, and have the facilitator monitor the discussions to make sure that they are fruitful. The facilitator should be sure to let the conversation go long enough to get to proposed action items and solutions. Each topic should end in an action item like the following:
        • Try something in the upcoming sprint.
          • Try a new approach
          • Change team working agreements
          • Change the definition of done
          • Some other thing to try
        • Take the discussion off-line into the upcoming sprint.
        • Agree to change nothing for one sprint and discuss it again at the next retrospective.
          • Another possible action item is, after discussing the topic, to keep things the way they are. I don’t like this kind of action item with important topics because it discourages trying new things. To me, a better solution is to try something for one Sprint and then retrospect again. A last ditch solution is to agree to keep things the way they are for one sprint and agree to definitely discuss it again in the next retro. If after two retros, there is no consensus on a suggested change, then it’s probably ok to go without an action item for that topic.
      • Each discussion should almost always end in an action item like the above.
  6. Make the agreed upon action items highly visible on your Scrum Board.

Variations

  • Remote Members strategy: For teams with remote members participating, consider a different setup where all members are on a conference call and simultaneously on a team wiki. Have each member create a wiki page for their suggested discussion topics. When voting, consider:
    • having the participants use their initials instead of hash marks to vote on the wiki page, OR
    • using the “secret ballot” strategy below.
  • Secret Ballot strategy: If the vote placing itself gets a little cagey for the team (people waiting to put their votes until the last second, in order to more strongly influence the top topics), consider having the team jot down their votes on a piece of paper privately, and then have the facilitator randomly go around the room asking team members to voice their votes (“I had 3 hash marks on topic ABC, 2 for topic GHI, and one for XYZ”).

Supplies

  • Preferably a room where the Scrum team can have discussions where no else can hear
  • Several white boards and white board markers.
    • Large post it note sheets (~2′ x 3′) can be substituted if you don’t have enough whiteboard space.
  • A facilitator to explain the rules and keep things moving.

Scrum Guide

This pattern implements the required elements of Sprint Retrospectives in the Scrum Guide. The required elements basically boil down to:

  • Do a Retro every Sprint
  • The entire Scrum Team participates
  • Time-box it to 1.5 hours for a 2 week Sprint, 3 hours for a one month Sprint, etc
  • Discuss what happened in the Sprint “with regards to people, relationships, process, and tools.”
  • Discuss what should be changed in the next Sprint.
  • Make a plan to implement the changes in the next Sprint.
    • Changes should be within the Scrum Framework. They should not be changes to the framework itself.

Origins

I’ve seen the “Plus Delta” analysis and “Dot Voting” (Hash Voting is a variation of Dot Voting) in several publications and web sites, but I don’t really know the origin of the techniques. This pattern is one I’ve developed over time in coaching Scrum Teams and it seems universally successful. Having said that, don’t forget the Best Practice – Change Up Your Retrospective Format. If anyone knows of the true origins of any technique described above, feel free to email me at the address on the home page and I’ll be happy to post it here.

Related advice

Related articles

Filed under: Scrum, ScrumMaster Tips, The Retrospective, Transparency | Leave a comment »

Best Practice – Make Retrospective Action Items Highly Visible

Posted on October 21, 2011 by charlesbradley

Here is how I define a Best Practice:

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

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.

Filed under: Bad Smells, Organizational Change, Scrum, ScrumMaster Tips, The Retrospective, Transparency | 1 Comment »

Best Practice – Review the Action Items from the Previous Retro in the Current Retro

Posted on October 19, 2011 by charlesbradley

Here is how I define a Best Practice:

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

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.

Filed under: Bad Smells, Scrum, ScrumMaster Tips, The Retrospective, Transparency | 2 Comments »

Best Practice – Change Up Your Retrospective Format

Posted on August 30, 2011 by charlesbradley

Here is how I define a Best Practice:

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

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?

.

Filed under: Scrum, ScrumMaster Tips, The Retrospective | 1 Comment »

%d bloggers like this: