Thou Shalt Use Pure Scrum

Are We Too Much Driven by "Purity"? Does It Always Work?

21 November 2013

Arijit Sarbagna

"This project can't be done on Scrum – the client only understands 'Use Case.' They will never give us a user story!"

"Nope -- there is no way we can have an MPP as a Scrum project!"


How often have we come across situations where people have complained about something similar to the points above? Don't freak out! Probably we just came across another Scrum Fundamentalist (aka: scrumdamentalist).

If we look into the situation, is it wrong to follow pure Scrum? Of course not. In fact, if pure Scrum works for our project -- voila! Nothing could be better than this. But the fact is, in real life we come across situations and projects where pure play doesn't seem to work, and we need to "inspect and adapt."

Let's take a few situations to dive deeper:
  1. No upfront design/architecture: Have we ever come across a decent house -- that was built without a design? How can we build anything without a plan? Yes, we do need up-front design, but let us not overdo that (that is, don't paint yourself into a corner). We don't wish to get to the debate of BDUF (Big Design Up Front) versus RDUF (Rough Design Up Front) -- but we do need design to start off.
  2. Daily collaboration: In an onsite-offshore model, we often come across situations where teams get into the cadence of having a daily collaboration. But before setting a cadence, ask yourselves, "Do we really need this?" Sure -- if there is a need, go ahead! But let us not impose collaboration on teams.
  3. Story points: Do we always have to have story points? Not really. If your team is in the first leg of its journey, story points may make sense to help team members understand the process better (I personally provide them an hour bucket to start with). But for an experienced team, let's cut them some slack. They might be more comfortable using t-shirt sizing to categorize their work. Some teams may even feel comfortable to doing a ROM PD estimate (though I personally prefer a combination of story points and WBS -- hourly break-down).
  4. Risk tracking: We often get into the feeling that we don't need to explicitly track risks, as we are covering them via release plans, sprint plans, and daily stand-ups. But no harm done if we start tracking them using a simple spreadsheet or, even simpler, if we leverage the ALM that we are using. It not only helps us in tracking risks and interrelated dependencies but it may also act as a nice set of empirical data for the future.
  5. Retrospect: We all hold retrospectives. But does it make sense to have a retrospective without taking the action items, or without driving the open items to closure? Does pure Scrum only talk about driving a retrospective and not driving the open items to resolution?
All said and done, the point is: Pure Scrum (that is another topic -- what we mean by "pure") may not always work, and we do need to make "adjustments" to make it work right in a given context. This is the need of fluid market dynamics, and this is what the Agile Manifesto guides us toward: "Responding to change over following a plan."

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: 4.2 (9 ratings)


It is very difficult to define "Pure Scrum".
The idea behind this article is really good - one should not blindly follow anything.

In one part we are saying 'ask yourself if it is really required?' and in another part we are saying 'there is no harm in doing this'. In many projects,I have seen, Scrum is implemented in a way that suits higher authority or person having longest shout in team.
Arijit Sarbagna, CSP,CSM, 11/21/2013 2:01:34 PM
Well said! I will largely agree and that is what makes onshore-offshore business more exciting! :)
Robert Weidner, CSP,CSM,CSPO, 11/21/2013 4:34:47 PM
I particularly liked the summation in your last paragraph. There can be no such thing as "pure" Scrum, because the focus is on continual process improvement. There is no ideal state of existence... it's about doing what works best for the current team, given the current effort. Each project, and team, is unique. Thus, Agile methodologies provide a framework, and within that framework we adapt and respond to change, while continuously refining our efforts. There is no end state... it's like fuzzy logic, we just keep trying to get better, all the time. There can be no “pure” state to an adaptive methodology.
Arijit Sarbagna, CSP,CSM, 11/22/2013 2:47:39 AM
@Robert: You said it well & very correctly. This framework does let us think & improvise as what could work best for the team. Manifesto also points us towards that - "Responding to change over following a plan" :)
David Lowe, CSP,CSM, 11/23/2013 3:59:25 PM
Robert, you said what I was thinking: 'Pure Scrum' fails at the first hurdle because it can't uphold the principle of improvement.

Arijit, quite a few people have recently mentioned about getting rid of estimates; I think this is a mistake because it's a good opportunity for teams and the PO to establish if they understand each other. Sure, let's not get obsessed (e.g. Planning Poker can be relaxed a bit), but I still think points have value.
Arijit Sarbagna, CSP,CSM, 11/24/2013 9:26:38 AM
@David: I totally agree! I am not suggesting removal of SP estimates, but would rather encourage being bit open about the process. I often come across teams - who are doing SP estimates based on a rigid hour bucket - which doesn't really lead anywhere. So, based on team's maturity - we should tweak/upgrade the process.
David Lowe, CSP,CSM, 12/18/2013 5:50:00 AM
Story point estimates "based on a rigid hour bucket"?! That's not story points then; that's estimating in hours. Agreed that practice can be lost immediately.
Brad Booton, CSP,CSM,CSPO, 12/19/2013 4:33:30 PM
To quote a friend of mine, "Do scrum by the book until you get good at it, then adjust." - Mike Cohn

Brad Booton
Joe Schweitzer, CSM, 12/20/2013 1:01:06 PM
Go article. I like the Shu Ha Ri principle. Break the rules when they no longer make sense. With my current engagement, I've learned to be flexible regarding expectations for initial design before we build out the backlog.
Arijit Sarbagna, CSP,CSM, 1/24/2014 11:16:07 AM
@Brad: Very well put!
@Joe: Shu-Ha-Ri is surely one good way of learning new techniques.

You must Login or Signup to comment.