Am I, or Am I Not, Using Scrum? That is the Question.

18 March 2007

Melanie Silver
State Farm Ins. Co.-RETIRED

Agile methodologies, processes, tools, and techniques are not new to software or product development. They have been around for many years. However, as companies start seeing an increased need to improve their time to market while maintaining quality, they are looking to adopt some of these agile techniques in favor over the traditional waterfall methods. Projects in many organizations are claiming to be using agile. They may be using XP (eXtreme Programming), AD (Agile Database Techniques), AM (Agile Modeling), or any number of other agile methods. They may also be using Scrum. The question being addressed here is whether, in fact, projects are using Scrum, or picking and choosing some of the techniques and calling it Scrum.

What is Scrum?

First, let’s look at what Scrum is. According to the Agile Alliance, Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Scrum does not dictate which engineering practices must be used. However, often times you will see it combined with XP to generate the benefits of agile development with the advantages of simple implementations. Scrum, used properly, significantly increases productivity and reduces time to market while facilitating adaptive, empirical systems development.

Scrum adheres to the values as defined in the Agile Manifesto:

“Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  •  Responding to change over following a plan.”

In addition, Scrum principles are the same principles embraced by the Agile Manifesto:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Working software is the primary measure of progress.

Scrum also has its own characteristics and practices:

  • Three basic roles: Product Owner, ScrumMaster, and Project Team
  • Product Backlog
  • Sprint Backlog
  • Sprint Planning Meeting
  • Daily Scrum Meeting
  • Thirty-day iterations, delivering increments of potentially shippable functionality at the end of each iteration
  • Sprint Reviews
  • Retrospectives

Remember, I stated earlier that Scrum uses an adaptive, empirical process for systems development. This approach demands flexibility and adaptability. Each project is different; that is why this adaptive, empirical approach can adapt to each project’s needs and provide for increased productivity and reduced time to market.

What Isn’t Scrum?

So, to the question of whether a project is, or is not, using Scrum. Let’s look at a few situations:

Scenario One:

The project decides to use Scrum to manage a software development project. Management gives approval to use Scrum but insists that the team follow the prescribed software development processes to ensure the team is doing what they are supposed to be doing.

Scenario Two:

The project decides to use Scrum to manage a non-software development project. The team is not collocated and the Product Owner doesn’t have time to prioritize the Product Backlog. The Product Owner indicates everything is top priority.

Scenario Three:

The project decides to use Scrum to manage a software development project. However, the team decides it doesn’t have time to conduct the retrospectives at the end of each iteration. They also decide to conduct the daily Scrum meeting only twice a week.

I could go on an on about project teams having to follow certain practices that are contrary to Scrum/agile methods, or skipping certain practices, or not adopting the characteristics inherent to Scrum teams. The question some are asking, are those projects still using Scrum? Is it smart to use only some of the Scrum techniques and not others? Employing and adhering to all of the techniques and characteristics of Scrum provides the synergy necessary to produce optimal results. Why would you want to settle for less?

Abandoning some of the practices that make Scrum successful gives the naysayer more opportunities to claim Scrum doesn’t work. One would have been much better off espousing the individual techniques that were used than claiming that the Scrum methodology was applied.

Using only certain Scrum techniques and adopting only some of the Scrum characteristics may not preclude you from claiming you are agile. However, I would use this analogy to show why you cannot profess to be using true Scrum: Can you say you've made a batch of chocolate chip cookies if you leave out the chocolate chips?


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Michael James, CST,CSP,CSM,REP, 3/20/2007 1:12:19 PM
Melanie, I agree with what you've written here. Scrum has very few parts, and none of them are redundant. Let's stick to a strict definition.

--mj
Anonymous, 3/26/2007 10:13:07 AM
> Three basic roles: Product Owner, ScrumMaster, and Project Team

I would agree but see no reason why one person can't perform one or more of these roles. I also see no harm in team members being acknowledged as specialists - e.g. dev, test, dba

> Product Backlog
> Sprint Backlog

These are absolutely critical aspects - without them you lack clarity of priorities and visibility of progress.

> Sprint Planning Meeting
> Daily Scrum Meeting
> Thirty-day iterations, delivering increments of potentially shippable functionality at the end of each iteration

Why 30 days? I find 28 very effective as your sprint planning always falls on a monday, you can use recurring meeting invites etc.

> Sprint Reviews
> Retrospectives

I agree generally though. The practices that constitute scrum can have value on their own but it's not scrum unless you take the whole package...

Cheers
Andy B
Anonymous, 3/29/2007 8:32:17 AM
I agree completely with the article, except that the Sprint length of 30 days can have some variance, whichever works best in your organisation... Except of course making it too long. What is too long? 40days? 2 months? 6 months? I believe 1 month is tops. Time enough to get things done and not too long to fall back into old habits.
Cheers, Ruud Rietveld (CSM, but still no login)
Kurt Crowley, CSP,CSM, 3/29/2007 8:32:24 AM
I think you have to make the distinction between the core processes/rules of Scrum and the ones that allow for some specialization or removal. I've seen several "derivations" of Scrum for the projects i've managed due to the difference in people, process, and product. I think variation of the "artifacts" is usually ok (i.e., shorter iterations, differently structured backlogs, etc.) but REMOVAL of the artifacts (no/limited daily scrum, no/limited product increments, quality shortcuts, etc.) are a recipe for disaster. Kurt C
Anonymous, 4/4/2007 8:58:58 AM
As the article indicates, there isn't much to Scrum. It is a framework within which an organization plays the game of complex product development. Whenever the basics of Scrum are changed, it is to accommodate a dysfunction, a bad practice, an inability in the development or product management organization. If this is a short term accommodation while the dysfunction is fixed, ok. If it is an accommodation because the organization won't fix it, well, then, it isn't Scrum any more. Would a football game still be a football game if it only had one quarter because everyone was out of shape?
Jeff Sutherland, PhD, CST,CSP,CSM,CSPO,REP, 4/4/2007 8:59:06 AM
In a conversation with a venture capitalist today who is investing in Agile companies, we discussed the following on who is doing Scrum:

"I've helped to start up several companies and two of the three were Scrum companies. Training and doing due diligence on startup Scrum implementation is critical. At the QCON conference in London a couple of
weeks ago I gave a presentation on Google's Scrum implementation. Out of about 200 people, 30 said they were doing Scrum. When I went over Nokia's requirements for iterative development, only 15 were even doing iterative development. When I asked if they met Nokia's requirement for calling their teams a Scrum implementation, only 3 out
of the 200 said they were really doing Scrum."

So his due diligence will be finding the three companies out of 30 who say they are doing Scrum!
Anonymous, 4/11/2007 12:52:27 PM
A good article, and I agree also with other commenters that in order to use Scrum, you pretty much have to take the whole package. However, from my own point of view, I'd like to see being a self-managing team highlighted in the determination of whether a team is doing Scrum or not. Though more importantly, I pretty much use it as one of the determinants in assessing whether a team/project is Agile, or merely using agile practices. - Petri Heiramo
Anonymous, 4/11/2007 12:52:32 PM
As Scrum and Agile techniques continue to grab more popularity, more and more people ask me about co-location for Agile/Scrum teams--I always tell them that face-to-face communication, in real time, is key to Scrum. It seems like team co-location has become a foregone conclusion among agile practitioners, and thus it isn't talked about enough as key to project success with Scrum. Agree? Disagree?
Anonymous, 4/11/2007 12:52:43 PM
I think the wrong question is being asked. I think the question that should be asked is what is the problem you are tying to solve, and will Scrum/Agile or Scrum/Agile techniques help to address or solve that problem.
Anonymous, 5/30/2007 6:26:56 PM
Can you make chocolate chip cookies without vanilla extract? How about with whole wheat flour? Margarine instead of butter? Scrum encourages common sense - and adaptivity. Apply scrum to scrum. What is left?
Jeremy Kenaghan, CSM, 7/17/2007 2:39:43 AM
A good idea by any other name would smell as sweet. And Scrum is full of good ideas.
Nicholas Cancelliere, CSM, 7/26/2007 2:20:17 PM
When people say "At Company B we use X on our IT project," what they're describing is what process they are using (x). As defined a process is a series of actions or steps taken in a systematic series of operations that are performed in order to produce something or achieve a particular result. So when a company isn't doing retrospectives, daily stand-ups, etc. they cannot say they are using Scrum. They can say "We are using a process that is based on Scrum," or "We are using a process that is very like Scrum." They cannot claim to be using Scrum though. That would be like saying "I am driving a car to your house," only to learn I pull up on a motorcycle. Seeing how upset you are I explain "Well it's really just like a car, just two less wheels, fewer seats, etc. but it gets you from point A to B, burns gas and shifts gears." There's a reason it isn't called a car at that point - because it isn't one!
Anonymous, 12/14/2007 6:18:06 AM
I'm not sure we should get hung up on whether a team is doing "pure Scrum". Scrum, as with any Agile methodology needs to be context-sensitive. Personally, I am opposed to thirty-day iterations in almost any context, preferring one-week or two-week cycles. I wrote more about this a while back at http://agilethinking.net/blog/2007/02/21/when-is-scrum-not-scrum/.
Nicholas Cancelliere, CSM, 1/3/2008 9:32:18 AM
I would agree with you Tobias, excepting at some point you have to recognize that someone isn't doing Scrum. It isn't enough to just be doing iterative development - a lot of methodologies use this pattern, and they're not Scrum. I don't think we should be overly zealous, but I do think we need to be mindful of what is Scrum and what it isn't. A lot of companies would claim to be doing Scrum but lack basic things like a Product Owner, or prioritized backlog, etc. They'll have chickens talking in stand-ups and the team controlled by a PM or technical lead rather than self-organizing. At some point you have to say "no ... you're not doing Scrum."
Naresh Verma, CSM, 1/7/2008 3:17:15 PM
I beileve that SCRUM can be used for other projects than SW development
Jay Conne, CSP,CSM, 1/9/2008 2:38:40 PM
I agree with Melanie's article and Michael James' summary reply. Any like Tobias, the 30 day iteration has never worked for my teams that have typically done 2-week cycles and in one case, 1-week Sprints with two teams that have continued for 9 months.

The elegance of Scrum as a framework, or to be more specific, an interaction model, is that it insures a certain minimum communication takes place between members of a creative team - and between that team and the sponsors/customers. It specifically acknowledges and supports a creative discovery process. Historical alternatives fail badly on this issue and typically have projects fail to meet commitments because they confuse speculation with specification.
Julya van Berkel, CSP,CSM,CSPO, 1/11/2008 3:10:23 AM
Changing from a more conservative environment to a Scrum way of working is a struggle. It requires strength of character, a good deal of convincing power and time. It also requires flexibility in bending your desire to do things the right way a soon as possible.
In implementing Scrum in a company that is Agile friendly and desires change but has many people that are wary of change, I have found that bending Scrum practices a little, and giving things time works to the advantage of Scrum. It shows Scrum IS agile, it shows many times that if you stick to a to the team familiar practice, they in time find out how this practice is not handy or convoluted after you have told them how Scrum does this. Converting to Scrum is sometimes being the Yoda. It is the Wax on Wax off technique of The Karate Kid. Sometimes the team has to experience and find out that using Scrum practices it beneficial to them. I will not quickly condemn people not proven practices from not using Scrum. Using the techniques we learned all are part of Scrum, using 30 day increments, retrospectives, daily meetings all make out to form Scrum. Is a one legged man any less a man?
What I am trying to say here is that companies claiming to be using Scrum and not completely adhering to all practices just need either time or coaching to find out that using the practices they omit would improve their process.
James Robinson, CSM, 4/24/2008 10:48:35 AM
Right on target. With Scrum's nearly unlimited flexibility i'd question projects that would wnat to eliminate one of it's core techniques. It's like building a room with only 3 walls. Stick to what scrum is asking for, at least in some fashion. Thought the exact Scrum terms aren't relavant to me. As long as the terms used are defined and the team has a common understanding it works. I also agree with Naresh that SW isn't the only projects that can benefit by using Scrum.
Melanie Silver, CSM, 4/25/2008 7:39:14 AM
Many folks have commented that the sprint durations can be other than 30-days. I totally agree and did not mean to imply anything to the contrary. The point is, a Scrum team uses 'short' iterations to provide incremental delivery. Some have even used 6-week iterations but one could argue that the feedback loop is too long at that point. I would be one of the first to agree that Scrum can be used on non-software development projects. In fact, I'm using it now for setting up a program office. Scenario two was pointing out the flaws in the Product Owner not prioritizing the backlog and indicating everything was priority #1, not the fact that they were using Scrum on a a non-software effort.
Luis Xavier Baena Mourão, CSM, 6/12/2008 9:40:38 AM
A basic aspect of SCRUM is realism. Introducing change including SCRUM in any organization is never easy and hardly ever culturally feasible out-of-the-box. In practice that requires compromising and adapting, taking a step forward, giving the organization time to interiorize whatever they can, and then taking another step. We know that not having a Product Owner, etc., is a path to failure; however it can take a couple of failed sprints to help the organization realize that you are not kidding them!
Lare Lekman, CSC,CSM,CSPO, 6/18/2008 5:55:41 PM
Like any process, Scrum is a reference model that should be (1) chosen and (2) implemented depending on the needs. I believe that using common sense and adapting to the situation, even if it required changing the reference model for a specific project, is what Scrum and agility is all about. Religious purism narrows down options, makes problem solving harder, and drives away civilized people. To me the important question is not whether you're implementing Scrum, but whether your implementation of Scrum actually works for you.
http://www.implementingscrum.com/blog/2006/09/25/scrum-the-silver-bullet-not/
James Peckham, CSP,CSM,CSPO, 7/10/2008 10:38:11 PM
Scrum is a very rigid and un-bending beast. Some organizations do not have the intestinal fortitude to take on the idea of scrum "All In" because of what it puts out in front of people. We frankly are doing a middle-down then bottom-up approach... first trying to teach self management and scrum values to team members then hoping they'll get good results with it so it can be pushed up towards executive management for the cultural change that MUST take place for scrum to take root. Unfortunately, the word scrum has been thrown' around quite a bit and "We are not doing scrum". It may in the end, be our un-doing... but honestly it's better than what we had before, no matter what it IS or IS NOT. We're closer to agile than we were before. As scrum master i tell a lot of my teammates: "We may never get scrum to work here, but the fact that we try to fit it into our world exposes the nasty beasties we need to work on and that's enough to make us more agile than before"
Herve Meftah, CSM, 7/17/2008 5:58:37 AM
I am completely agreed with this article. In case of an entirely project developed offshore some Scrum rules should be reinforced; such as Scrum Instant Messaging daily meetings. The key point is having a project on tracks at the first Sprint by setting up a team ΓÇ£momentumΓÇ¥, based on 2 factors; this ability to solve issues and its velocity. This could be achieved using dedicated tracking tools and ΓÇ£socializing appsΓÇ¥; quiz, poll vote, project terms crosswords.
Andre Pantaliao Ferreira, CSM, 10/31/2008 8:41:10 AM
I agree with the ones that said that we should not get hung up with "pure Scrum".
I'm afraid of this kind of discussion because the next step is to start a certification to companies that are "pure Scrum users".


We have to focus on the reasons someone had to change his Scrum, why he is not using some technique. We may find a good solution, a new idea. This will be the base to keep Scrum evolving.
Stephen Palmer, CSM, 11/3/2008 6:49:32 AM
Agile is about adapting. In the end it is producing working software that is important not the name of the process. Having said that, it is important to understand Scrum, the principles behind it, etc, etc, before adapting otherwise you run the risk of falling back into old habits. Studying other agile approaches like FDD and XP help. In an ideal world, I'd always recommend starting with 'out of the box' Scrum and use retrospectives to tweak the process where and when necessary. However, my world is rarely ideal and often, the starting point is not where I'd like it (as in the old joke 'Lost person: How do I get to xyz? Local:Well, I wouldn't start from here').
Christophe Le Coent, CSM, 1/25/2009 3:28:16 PM
"We frankly are doing a middle-down then bottom-up approach []... the cultural change that MUST take place for scrum to take root": I work in the same context, so even if it is not pure Scrum, I am always referring to the Agile Manifesto, to Agile principles and Techniques, and yes producing working software is more important than doing pure Scrum. Scrum is a very good reference but one size does not fit all. It is a good target to aim at.
James Peckham, CSP,CSM,CSPO, 3/16/2009 10:01:07 PM
Christophe, good point. Scrum is a process control framework. Just by introducing it as a bar to measure your progress by it's doing it's job! :)
Sylvain Jean, CSM, 5/19/2009 2:58:29 PM
One of the values of the Scrum process is to allow problems to be highly visible and to allow for them to be resolved using inspection and adaptation. It is sometime tempting to "resolve" these apparent problems by hiding them instead of modifying the behaviors or practices that are causing them. On top of that, in an environment were adopting Scrum is a struggle, the Scrum process may be seen as the actual cause the problem. It is not surprising to see that modifying Scrum is often seen as an easy way out.
Before attempting to modify the Scrum process one should read the section 5 of the book by Ken Schwaber and Mike Beedle: ΓÇ£Agile Software Development with ScrumΓÇ¥ to understand really why Scrum works and avoid ending up with something that defeat the purpose entirely.
Mike Collins, CSM, 8/21/2009 2:04:40 PM
Scrum is about adaptability and doing what makes sense. Therefore, it is important not to take a religious all or nothing attitude towards its adoption by an organization. Different organizations have different needs, problems, and cultures. If we simply demand that an organization instantly accommodate agile values adopt "pure" scrum processes, we will guarantee failure. Scrum is an empirical, incremental process based on the "inspect and adapt" mechanism. In my opinion, it makes a lot of sense to use the same philosophy when it comes to implementing Scrum in an organization. This means that in some situations it may be wise to introduce scrum practices incrementally. Most, if not all, of the Scrum practices have value in their own right and it is not necessary to adopt all of them simultaneously to see improvement. This incremental approach can ease the transition for organizations that are resistant to change. It is sometimes easier to chip away at a wall of resistance than to try to knock it down in one fell swoop. Some teams will adopt scrum practices more quickly than others but that is okay. Self management of teams is another scrum value and trying to force teams to adopt "pure" scrum all at once goes against that value. I belong to an organization that began using scrum about a year and a half ago and we are still in transition period. Some teams have been very successful in fully adopting scrum while others are introducing the practices incrementally. Things are moving in the right direction and the trend is toward more widespread adoption across all the teams but I can tell you first hand that this would not be the case if we demanded an "all or nothing" approach.

Gaofeng Wang, CSM, 9/25/2010 2:56:59 AM
Scrum is a simple but not easy way. :-)

You must Login or Signup to comment.