Scrum as model not a rulebook

My starting point for a process approach for a scaling development team is generally Scrum.  However I would emphasise that this is not the only starting point. This is one Play and others might choose a different approach.

We should be clear from the start that “Scrum” and “Agile” are different things, despite frequent confusion. 

• Agile is a set of principles intended to improve software development in complex environments. 
• Scrum is a framework of suggested approaches to enable this. 

You can follow the Agile principles without using Scrum (and many people do so).

“Scrum” and “Agile” are different things

I am not teaching Scrum on this site. There are plenty of materials about what Scrum is and how it functions. A good starting point is the official Scrum Guide.

There are some good reasons to consider Scrum.  It is by far the most well-known Agile approach.  Since a common shared language is one of our key goals, the wide awareness is clearly going to give us a head start.

Scrum training is widely available in forms varying from free videos on good practice to face to face presented training courses.  This is going to make on-boarding new staff into the organization easier than if we selected a proprietary or little used approach. 

Scrum certification

As well as training, there is also a large industry in certification and I’m not sure that is a point in Scrum’s favour.  I’ve not found a need to have team members certified in order to work effectively.  I believe in building your own Playbook. I’ve preferred non-certified courses which tend to allow more flexibility .

Ken Schwaber, one of the creators of Scrum, tells a story about certification from the early days of Scrum.  He was once contacted by an angry business leader.  He had carefully chosen someone who had been certified from one of Ken’s courses.  As the leader saw it “The certification from an organization that you headed clearly differentiated him”.  But the chosen person performed poorly and the leader complained about the quality of the certification.  Ken pointed out that the certification had never said anything about the quality of the individual’s skills.

People asked for certification of attendance. 
I had never expected that the certifications would be used as a means of demonstrating expertise.

“Building an Agile Organization” – Ken Schwaber

Where does the name come from?

“Scrum” is not a natural name to adopt for a development approach.  It’s a game term.  And a game term from rugby, which has limited global adoption and low presence in the US.  The US is 14^th on the list of rugby playing nations by number of participants with only around 2% of the world’s rugby players (data from World Rugby).  It’s perhaps not an obvious choice for the name of a technology approach popularised in the US.

Of course the use of rugby as an analogy should be less of a surprise to the reader here because we have already met this idea.  The New New Product Development Game introduces the analogy using rugby as the representation of the ultimate team approach.  Rugby is an ideal game for this as it is designed around individual commitment (it’s a physical contact game) but team success (no individual can run up the pitch and succeed alone).  With the authors being Japanese this is perhaps a more understandable analogy since Japan is third on the global list by number of rugby players.

Interestingly the term “Scrum” is never used in Takeuchi and Nonaka’s original paper to represent the Agile style of working which is always referred to as “the rugby game”.  It is however very clear and explicitly stated when “Scrum” was first discussed that the name was intended as a direct reference to the “rugby game” analogy in Takeuchi and Nonaka’s paper. 

Scrum flexibility

Scrum does not position itself as a “Methodology”.  It states this very strongly.  When we talk about “methodology” we are most likely to mean a specific set of methods which form a consistent system. There is an implication that a set of methods represents a deterministic behaviour and a solution for a complicated problem, not a complex one.

By stating that Scrum “is not a methodology”, the authors are emphasising that they are in a complex problem space.  Therefore there will be no set of rigid methods which will solve the problems.

That fits well with what I’m looking for in a process model to fit the Playbook.  I want flexibility with guidance, not a prescribed set of steps. 

We need a model, not a methodology.

Why is Scrum a good model?

In 2011 Ken Schwaber came to an important conclusion about Scrum.  He realised that Scrum could never completely describe all projects and all usages.  You could try and achieve that objective, but in a complex environment you would necessarily fail. Scrum has kept the scope to a very specific set of processes.  In these areas Scrum proposes good practices.  But in other areas, it doesn’t get involved and explicitly says you should use whatever processes work for you.

This happens to be just what I’m looking for in a process model for the scaling organization.  We need a clear set of language and tools for the specific areas where we are using them.  But we also need not to be clashing with what we might be doing in other areas. 

For example, Scrum says nothing about line management.  That is not because how individuals are managed isn’t important.  It’s not because the authors believe line management doesn’t matter.  It certainly doesn’t mean that if you follow Scrum you shouldn’t have an answer for how your organization manages people.  That is both a moral and legal requirement.  But line management and Scrum are independent dimensions.  The development processes can fit with a range of different management processes. 

Good practices

The Scrum Guide says that Scrum is a “framework not a methodology”.  I would describe it as a model of a very simple environment.  This simple environment is used to describe a set of approaches.  Your real scenarios are probably more complex.  But you can use Scrum as a basis to be extended for real problems

You should ensure everyone is familiar with whatever model and processes you use. By keeping the model simple, Scrum gives a set of good tools and language.  It can describe them clearly.  This can ground the organization and work as a model that everyone understands. 

Scrum does not tell you how to manage every aspect of a development.  For me, its value is in giving clarity about what we are trying to do and why we choose to do something in a specific way.