This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
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.