Scrum Orthodoxy

I’ve finished my first week and my first class as a Danube employee and trainer.

A trainer named Dan led the class, while my role was to simply watch and learn. Having spent so much time teaching a CSM class internally at my previous job, my concern was that I might not be teaching the class in a way consistent with other trainers. I expected that there might be minor differences in the examples used and certainly in some of the slides. Imagine my surprise when Dan told the entire class never to collect task updates on the sprint backlog prior to the daily Scrum, but, rather, to collect those updates during the daily Scrum! For two years, I’ve been teaching my classes to never update the sprint backlog during a daily Scrum because it prevents team members from listening to one another! While I expected minor differences in how the class was taught, I never expected to be at odds with something as basic and fundamental as this.

Needless to say, I followed up with Dan immediately after the class. I asked him, “Why would you have team members update the sprint backlog during the daily Scrum? Doesn’t this get in the way of everyone actually listening to everyone else?”

“Not at all,” Dan said, “I have each member of the team go up to the task board and update their cards as they talk about them.”

As Dan answered the question, it occurred to me that many of the Scrum teams I’ve worked with in the past hold their daily Scrums standing or sitting around a table, not standing by the task board. Both approaches are valid and, frankly, were I to work with a Scrum team that wanted to do its daily Scrum around a task board, I would agree that Dan’s approach would be most effective.

Breathing a sigh of relief that I wasn’t that far off the mark, I realized that while the fundamentals of Scrum are simple, we all have our different ways of approaching how we actually “do” Scrum. Consequently, while there are instances where each and every one of us feels very strongly about our approach, we must always keep in mind that our environment and our perspective have a significant impact on how we approach Scrum.

Case in point: I was involved in a series of e-mails on the Scrum development discussion list regarding where technical debt items should be placed and how they should be handled. I said that there should only be one backlog and that all technical debt items should be in the product backlog with everything else. During the course of the e-mail exchange, another experienced trainer, in no uncertain terms, said the technical debt items should never be in the product backlog. That’s when I remembered what happened in Dan’s class and I decided that we must both be right for the situations in which we worked.

Those who are new to Scrum and struggle with its implementation and practice look to those of us with more experience for our guidance. Trainers and non-trainers alike, we need to temper our words and combine our answers with the context in which those answers fit.

So, should technical debt items be stored in the Product Backlog? Well, yes… and no. Yes, Scrum says that the Product Backlog contains everything that you plan to do to the product – features, defects, whatever. However, there may be times when it’s better for each Scrum team to manage its technical debt outside the product backlog. The decision has to be made on a case-by-case basis… but you now have at least two different valid approaches to try. One of them is likely to work well for you.

We work in the relatively unexplored frontier of Agile development. Those of us in the position of coaching or training must always remain aware that people ask us questions because they find our experiences to be relevant and our opinions important. If we make black-and-white statements about how Scrum is (or is not) to be used, we will find ourselves becoming very un-Agile, incapable of flexible adaptation, and unworthy of our standing.

So, I begin my first week with Danube learning a very important lesson: As users of Scrum, more so than any book, we are Scrum. Scrum will become as effective or as useless as we allow it to become. We must continue to inspect and adapt ourselves and be careful not to ever assume we know so much about Scrum as to say something always (or never) is the case.

Posted in Agile
2 comments on “Scrum Orthodoxy
  1. Michael James says:

    I had the privilege of working with Jim Schiel this week at a CSM class in Manhattan. I’m blessed to be on a team with the likes of Kane Mar, Dan Rawsthorne, and now Jim Schiel.

    Some class participants were eager to discuss an interesting situation at their organization. We found ourselves in the position of trying to second guess thirdhand stories about past decisions made by a Scrum coach and an onsite uber ScrumMaster.

    That night it occurred to me our role as Scrum trainers is to impart fundamental principals and past experience so that people can make their own judgements about particular circumstances they know much more about than we do.

    The very few “rules” of Scrum are there to exploit basic laws of nature. Stephen Covey might call them “lighthouse principles” — you don’t break them, you only break yourself against them.

    * If you extend a Sprint past the original commitment, the Scrum Police aren’t going to arrest you, but you’ll probably miss an opportunity to learn something that would make you a better performing team in the future.
    * If you stuff a team with more people that can easily keep track of each other (about seven), self organization will probably suffer.
    * If you fail to ratchet up your definition of “done”, you’ll either slip your release date until you do, or ship a shoddy product.

    You already knew this, but your friendly neighborhood Scrum rules are there to counteract your natural tendency toward self deception. When breaking a Scrum rule, I suggest asking yourself whether you’re doing this to mask an organizational impediment.

    Recommendations on the other hand, are more situational — sometimes wrong for a given circumstance. Should the taskboard be updated during the Daily Scrum, or beforehand? Should technical debt be exposed on the Product Backlog? Can we have a team of ten if they have really good teamwork skills? Is adding a new person to a team more harmful than taking someone away? Ask ten Agile experts and get eleven different answers. We’ve all discovered different tools to get on the same pathway.


  2. Paul Parker says:

    I’ve worked with various Scrum teams from several organizations with the intent to follow “good” Scrum practices. In each case we did things a little differently to fit the team and organization while maintaining the spirit of Scrum. I like the idea of using the physical or virtual task board during the daily Scrum to capture updates “live”; it provides the visualization of the team’s progress and commitment.

Leave a Reply

Your email address will not be published. Required fields are marked *