Practicing Scrum

Awhile back I created a sort of “business speak” glossary of Scrum terms. Often times when I’m introducing scrum to a new environment with a wide audience I will use these terms in place of the technical terms provided by Scrum to get people used to the process without scaring them away with jargon. Feel free to download it here. If you have your own favorites post a comment and we can create a running list.

Normally when I introduce Scrum and Agile to a company of any reasonable size they complain that it’s too lightweight to work for their particular business. I’m sure we’ve all heard that at one time or another.  This morning during a daily standup with a current client however I noticed something rather funny. I had heard that people in the organization were talking about the task board my team has filling an entire wall of a conference room. Anyone who’s done Scrum has probably used such a mechanism (i.e. tape, sticky notes, index cards etc.). Anyway on the opposite I saw a different set of stickies someone else had put up…

Apparently when there’s no process Scrum can seem quite heavy weight. In retaliation for this clever jibe I added the following notation using a wet erase marker to the above, “Agile Extreme - A process so lightweight it’s invisible”

So we all know that Scrum is one of the best tools around for developing software. I think it is also fairly well established that Scrum is great for most new product development types of endeavors. I have made the case for several years that Scrum can be applied to almost any problem, but without any real evidence.

Recently I’ve begun coaching an organization that is far more on the creative side of the business landscape (i.e. advertising, new media, graphic design) that is interested in trying Scrum in their environment. In many respects their situation is ideal (engaged product owners, acceptance and acknowledgement of flexible scope, willingness to push decision making downstream by empowering the team, general openness to new ideas).

The irony, however is that the usual battles I fight when introducing Scrum somewhere new are nowhere to be found. There is no investment in “Big Up Front Planning”. There is no respect given to PMI and traditional project management methods. There is some of the “throw it over the wall” assembly line mentality. Ultimately the issues are mostly centered around the lack of a coherent “team” as a unique entity (which proceeds directly from the assembly line approach) and a very hard dividing line between different disciplines (e.g. creative versus technical).

I’m interested in know about what experiences other practitioners have had implementing Scrum in a non-traditional environment.

Adapted from material originally published 4/15/2008

Very often when we are introducing Scrum to a new environment we often get into debates, sometimes heated, with people who question the validity, truth and or value of a particular agile or Scrum principle. My general feeling is that any time spent having a philosophical argument with a client/product owner is time not spent adding value.

In my experience product owners and their organizations care about results. Rather than trying to convince someone of a particular point with a carefully thought out and bullet proof logical argument (which probably won’t work) figure out what result the product owner wants. If the PO says he wants “metrics” solicit him for the measure he considers most important. Ask the PO what he wants to measure and why? Going down a philosophical rabbit hole will not get the PO or the organization any closer to embracing Scrum. Getting results does that.

Re: Metrics

As a math geek who spent years gathering, interpreting, revising and deriving all sorts of fancy “scientifical” metrics for measuring everything you can imagine I have found that more often then not metrics obscure our picture of reality rather than clarifying it. There is only one metric that matters “working product as a measure of progess” everything else is, in my opinion, academic. Actually there is one other metric that matters to business owners…ROI. But then I would put an experienced high performance Scrum team up against anyone in that category and confidently guarantee greater ROI than a team using traditional methods.

Adapted from material originally published 11/7/2007

What do we say to the accusation that we’re not really doing Scrum unless we have a “releasable product” at the end of each and every sprint? I have a couple thoughts. One answer is more theoretical and one is a practical answer to the question.

Whenever I hear someone, regardless of who it is, say, “You’re not doing Scrum because…,” my initial response is always to evaluate the understanding of Scrum implicit in the statement. Scrum has extremely few moving parts. That fact makes it extremely flexible, but likewise open to many different interpretations and, consequently, many different ways to approach the use of Scrum in practice. Anyone making such pronouncements should be cautious. Conversely it is possible to adhere to the “letter of the law but not the spirit”. Ultimately our goal is to do development better. A slavish devotion to a particular dogma is counterproductive to that aim (and is in fact what has plagued PMI style project management for decades).

Now in terms of the question asked I would say that the terms are in adequately stated. What is meant by “releaseable product”? It strikes me that there are crucial modfiers missing from that term. It should read, “potentially releaseable product increment.” It is an absurd standard to suggest, if this is what’s really meant, to have a releaseable product at the end of every sprint. The first couple of sprints Scrum frontloads architecture and infrastructure types of tasks onto the backlog. Those are unlikely to result in a releaseable product in all but the simplest situations.

So then is it simple pedantry to distinguish between “releaseable product” and “potentially releaseable product increment”? I would say no. A releaseable product is, by definition, “ready for primetime”. That is to say its ready for end users and will do something useful. That is an end goal of the development enterprise but it is not an intermediate step. Conversely a “potentially releaseable product increment” is a small piece of the product that does something, no matter how small that something is, and which has been as thoroughly vetted as possible with appropriate levels of design, development, and testing. There is no requirement, in my opinion, that it must do something useful for the target user by itself.

Originally Published 11/27/2007

In scrumdevelopment@yahoogroups.com, Allen Bierbaum said, “Recently…my management posed a very pointed and in my opinion valid question about Scrum. Namely, how do you track (and respond to) the critical path on a long duration project.”

This whole discussion is likely to be predicated on the assumption that calculating and managing a project’s critical path has business value that outweighs it’s cost in terms of overhead and that the results are sufficiently predictive. I think that would need to be established first or there’s no reason to ask how Scrum handles critical path or what concept within scrum is analogous to critical path.

Accepting for the sake of argument that critical path management adds value to the software development enterprise, I want to make sure we are all on the same page as to what constitutes the critical path in a project. In the most informal sense, for those unfamiliar with the term, the critical path is that sequence of tasks throughout the entire project which serve as the minimum possible timeframe for delivery. In a formal PMBOK sense the critical path is calculated by creating a network diagram of that all the tasks required to complete the project and determining that path through that diagram which contains no slack. This is meant to tell us in a precise and “scientific” way the information encapsulated in the informal definition.

The goal of this rather complex and lengthy exercise is ostensibly to tell us which tasks, if they slip, will affect delivery. It is assumed in PMI circles (and in management in general) that this is a valid exercise that will help us monitor progress and allow us to correct course in the event of contingencies.

The foregoing being established the first thing to point out is that the whole concept of critical path and critical path project management (and related concepts like critical chain etc.) is predicated on the assumption that you can identify ALL the tasks required to create a given software product (as defined by a business case or product vision), that you can accurately estimate the duration of each and every task, that you can determine what ALL the interdependencies between tasks are and that you can do all this up front. In short it is predicated entirely on assumptions that are entirely contrary to agile principles.

Given the preceding the short answer to the question of how Scrum handles critical path is that it doesn’t because the whole idea is 100% voodoo that only gives the appearance of structured and scientific predictions. Of course that bald assertion is not likely to convince a proponent of critical path management unless you unpack it and defend it further.

When I have a chance I will try to elaborate. The first step though is to ask management how effective managing the critical path has been on prior projects. The answer to that question largely determines how to proceed with the dialog.

Originally published June 28th, 2006

A ScrumDevelopment YahooGroup forum participant writes, “A sprint is supposed to be fixed. This mean we are not suppose to add task to the sprint.”

Nothing could be further from the truth. While the backlog selected for a Sprint should remain unchanged, the actual work for the Sprint, in the form of tasks, is definitely not. At the 2nd Sprint Planning Meeting, the team determines which tasks it thinks are necessary to complete the items in the selected backlog. This will never be exhaustive because the work for the Sprint emerges over time. What that means is that tasks get added to the Sprint backlog as they are identified. If you are tracking sprint progress in a burndown chart (which you definitely should be) the usual trend is for the “hours remaining” to go up the first several days of the Sprint and then trend downward.

With that in mind, how do you handle defects? Firstly any piece of code with a sufficiently serious defect is not “potentially shippable” and as such cannot be considered complete until the defect is resolved. So the first course of action is to add a defect as one of the tasks for a given backlog item and fix it within the Sprint. The code should be as defect free as possible in order to consider your Sprint goal achieved on Day 30. It is sometimes the case that defects are not serious enough to warrant rejection of a backlog item or are discovered in later Sprints. For these types of situations I usually include a backlog item (or user story if you prefer that terminology) called “defects” and include each defect that needs to be resolved as a task for that item. Another strategy I’ve used is to have a short (2 week) “integration” Sprint [NB: I’ve recently seen this refered to as a “stabilization sprint”] prior to each interim release (say every 3-6 Sprints) and focus on defect resolution and other non-backlog issues and items. This is not standard Scrum, but I’ve found it works pretty well.

The OP goes on, “However, bugs are often found in the middle of a sprint. Many of the bugs may be deferred to the next sprint, but some bugs must be fixed by the sprint’s end. How do you folks handle this?”

Any defects that prevent the code from being “potentially shippable” must be resolved before the end of the Sprint in order for the related backlog item (user story) to be considered complete. If it cannot be that backlog item should be placed back on the product backlog. For defects that are not “show stoppers” you might try the strategy I suggested above (i.e. a user story specifically for bugs).

Finally a note about automated unit testing and continous integration. The real key to reducing defects in your code is not Scrum or anything to do with Agile per se, but rather a robust automated unit testing strategy. I tend to favor test driven development using NUnit (for.NET or JUnit or some other harness for other platforms). By writing and performing automated unit tests on the smallest increments of code (say at the method level within a class in C#) you dramatically reduce the overall number of serious defects that make it into the build, make them easier to identify and enforce the notion that defect resolution is a sprint task that’s part of achieving the overall sprint goal. Additionally if you get developers in the habit of writing automated unit tests first the way they think about the code is more structured and disciplined and the code ends up being of a much higher quality than if the developer writes some code and then performs “manual” unit testing (which isn’t really unit testing in my opinion). If you’re going to do automated unit testing you may as well as throw in continuous (or at least daily) integration with a tool like CruiseControl.

After a false start last fall ScrumPractitioner.com is relaunching the Practicing Scrum blog. We’re going to start with a selection of “greatest hits” from previous blog entries and discussion forum posts. If you would like to contribute and are a CSP, CST or CSC please email JSFosdickCSP@ScrumPractitioner.com.

ScrumPractitioner.com also wants to remind readers that anyone with a CSM, CSP or CST/CSC certification is eligible for a free ScrumPractioner.com email account.