The Schizophrenia of Scrum

I sometimes get the feeling that there are two versions of Scrum.

The first version is the one that says that “Scrum is not a methodology, a defined process or set of procedures. it's an open development framework.” (Jeff Sutherland) and “Scrum is a values-based framework; it is not a methodology, not a process, not a tool.” (Tobias Mayer)

Scrum version 1 is the Agile version of Scrum. It is the one that values people over process, and principles over tools. It says Scrum is a framework that is open to change, and it can even change itself.

The second version is the one that talks about “the dangers of customizing Scrum inappropriately and the problems that arise from an incomplete Scrum implementation” (Ken Schwaber) and “A Scrum checklist as a simple tool to assess your current implementation of Scrum” (Henrik Kniberg)

Scrum version 2 is the Defined version of Scrum. It is the one that says your implementation and customization of Scrum can be good or bad, based on a small number of best practices, as defined by its founders.

But the practices that Scrum version 2 claims to be essential (like having a Scrum Master, daily stand-up meetings, and weekly sprints) are usually process-based, not value-based. People tick off best practices, not values and principles.

So my question then is, if I do Kanban, while still adhering to the values and principles of Scrum (but with my own replacements for its defined practices), am I then still doing Scrum?

If you answer 'No,' then apparently part of the Scrum framework is still about process, not about values.

If you answer 'Yes,' then apparently you think it's possible to do Scrum without anyone being able to recognize it as such.

I fear that I'm on both sides, and I'm feeling quite schizophrenic…

(image by Victor Bezrukov)

Twitter TwitterRss SubscribeEmail NewsletterLinkedIn LinkedInSlideShare SlideShare

Latest, greatest and favoritest posts:

In Defense of Scrum (Please Stop Pissing on It)

Self-Organization vs. Emergence

ScrumButs Are the Best Part of Scrum
  • The Zen of Scrum (video)
  • The Nonsense of Leadership (Princes and Priests)
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://www.rgoarchitects.com Arnon Rotem-Gal-Oz

    The real question is does it matter. What you want to achieve is a development process that both you and your teams are comfortable with and helps you deliver business value.
    If it goes by this name or that or doesn’t have a name is of no consequence.

  • http://blog.brodzinski.com Pawel Brodzinski

    I have a better answer: “who cares?” If my team is doing well I don’t really care much which label can be attached to our process/method/set of techniques/you name it.
    Is it any value in following Scrum? I mean in the simple fact you do follow Scrum. Or the value is in more flexible tackling of problems, improved productivity, better quality, more happiness among engineers or whatever makes you to stick with Scrum?
    I don’t take pride in following a specific methodology. I take pride in building high-quality product which can reflect changing market needs. I could do it with Scrum, I could do it with Kanban but I could also do it with spiral approach. I choose whatever suit me best in given environment.
    But if you put the gun at my head and forced me to choose or threaten you’d kill a kitten for every minute of my hesitation I’d go rather for approach no 1. I believe my environment differs from what Ken or Henrik has seen in their lives (since every environment is unique) thus tweaking general framework would likely bring better results. At least when it is done by some reasonable and experienced person.

  • http://profile.typepad.com/6p0120a674d02f970c www.facebook.com/profile.php?id=1047505248

    any management process involving daily meetings churns my stomach!

  • http://machielgroeneveld.nl Machiel Groeneveld

    Something can be said for both view points. If you understand why people are promoting one or the other, you’ll understand. I don’t see schizophrenia, I see a struggle to fit Scrum and its use into a single definition for all people at all times. Sometimes I long for the times when Scrum was presented simple as ‘a way to do projects’.

  • http://www.guerrillaprojectmanagement.com Samad Aidane

    When will agile grow up?
    The most cited argument against customizing or partially implementing agile is that doing so prevents the organization from realizing Agile full benefits such as speed, efficiency, and cost savings. In my experience, this argument comes mainly from the hard core agile evangelists. Most practitioners I know out there want flexibility to pick and choose what agile practices to introduce to their organizations and when.
    Insisting that an agile method (or any method for that matter) must be implemented exactly how it was originally conceived in all projects becomes an obstacle to its adoption in many organizations and projects. Isn’t it a core part of Agile to change the process over time and make it more effective?
    ERP implementation projects can benefit greatly from some of the agile practices of scrum. However, the idea of a product owner is unfeasible in a complex ERP upgrade project, as there are multiple owner (Director of HR, Director of Finance, Director of IT…). To continue to insist that the business nominates a single person, in such projects, ignores the reality that no one person in today’s complex organizations can be the chief of answers.
    There is nothing wrong with having multiple product owners in this case, as long as they can prioritize the backlog. It may not be an elegant solution but it is a practical one that makes it possible for agile to scale and for the team to reach the finish line and deliver success. Isn’t that what is more important after all?
    The reality of organizations today is that they don’t come in a very neatly packaged configuration to which we can apply a single methodology. We need to selectively adopt, adapt, and apply whatever agile practices that can help us deliver projects successfully.
    Agile methods need to continue to evolve beyond their initial framework and practices. We are seeing this now with teams moving from scrum or XP to scrumban or kanban. This is a good thing, despite what you hear from the methodology bullies.

How to Change the World - free Workout - free
CLOSE