I noticed that a lot of people miss hearing that Scrum is a framework, not a method. It means that within Scrum you can (must) employ some other processes and techniques. So, what are the gaps that we have to fill in?
The largest gap is in engineering practices. This is because Scrum does not provide any of it. In this field things are very clear – for sure you should introduce some XP practices (continuous integration, pair programming, TDD,…) in parallel with Scrum.
The second group of ingredients for spicing up our Scrum are what M.Cohn call GASPs – generally accepted practices of Scrum. These are not rules, so practicing or not practicing it does not make you having or not having Scrum. At this point, it is probably very interesting that lot of people doesn’t really know what is a part of formal Scrum definition and what is not. For those of you who feel uncertain I recommend reading of Scrum Guide (http://www.scrum.org/Scrum-Guides) as some kind of “formal” Scrum definition. What I feel is a really necessary list of GASP that everyone should add is: user stories, story points and Scrum board. Close to it are release planning and backlog grooming meeting, but I think it depends about project nature do you need it or not.
Additionally, there is a Scrum add-on introduced by M.Lacey in his book Scrum Field Guide that is not so widely known, but I like it and use it a lot. It is called Forth question in Scrum. At daily standup, additionally to a standard three questions, you ask “On a scale of 1 – 10, how confident are you that we will accomplish the goal of this Sprint?”. I usually use it with persons that are introverts and I have already felt the benefits of this approach.
And now we come to an interesting part – what about really modifying Scrum? I mean, to break the rules? But before we dig in deeper into this topic, I must say something very important: Do not modify Scrum before you understand Scrum principles. Again: Do not modify Scrum before you understand Scrum principles. For example, simply deciding not to do retrospective meetings without any other “replacement tool” to enable improvement is a very bad thing.
OK, back to the track. Recently two Scrum modifications occupied my mind. The first one is Scrumban – a hybrid process between Scrum and Kanban. Scrumban or Scrum-ban tries to use best things from Scrum and Kanban. I’m not going to describe Scrumban here because there are very good descriptions of it elsewhere (e.g. here), but I’d like to say that Scrumban really looks usable for maintenance and event driven environments. Also, it has a very strong growth of popularity (e.g. according to VersionOne’s State of Agile Survey).
The second Scrum modification is something that I heard from Hakan Forss at Agile Adria conference 2013. Hakan proposes to replace retrospective meetings with Toyota improvement kata. In short, Toyota improvement kata states that we have to set up some final state where we want to be and then, by doing experiments, we try to get there in multiple steps. I must admit that I was interested by this staff and right now I’m looking for a good opportunity to try it.
You may have noticed that both “real” modifications of Scrum comes from Lean. This is not surprising because Lean is entering into software development very fast. Mostly because of Kanban. As we all know, a change is in a heart of agile development, so maybe a Scrum will change significantly in upcoming years. Recently, Jeff Sutherland and Ken Schwaber announced a new version of Scrum Guide. We don’t know details yet, but maybe some non-cosmetics changes are close to be published. I mean, formally. Because in practice, these changes are already in place.