When I first started doing Scrum I was focused on project delivery. As a software professional I wanted to find better ways of delivering customer value and Scrum made total sense to me.
But as I applied Scrum, I started to realise that Scrum isn't actually about delivery; it is about change. Now as an agile coach I spend the majority of my time on change management. In this post I investigate why Scrum is actually about change and how you can use it for approaching change.
Most companies start with Scrum at the delivery level. There is often some sort of negative compelling event that triggers a desire for change. Examples I have experienced include “we can't afford another 6.2 release” or “we are getting smashed in the market my competitor X”. (For some bizarre reason few firms seem to proactively adopt Scrum is a strategic approach to building sustainable competitive advantage and preventing disaster in the first place, despite the clear benefits).
With the right training and coaching, they will get up to speed relatively quickly. But what a good agile coach will prepare them for a programme of on-going change. And the change is not limited to just technology.
In 2006 Ken Schwaber published a simple, one page article called “Scrum is Hard and Disruptive”. I usually provide attendees a copy of this simple article in Scrum training as it contains succinct and relevant points that summarise Scrum nicely. In particular these two:
An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.
Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.
Ken Schwaber
Scrum has three legs"
- Transparency: the aspects of the process that affect the outcome are visible, as well as what is being seen must be known in its realistic state;
- Inspection: frequent enough inspection allows the detection of unacceptable variances. The frequency of inspection should not exceed the tolerance to inspection.
- Adaptation: if inspection reveals elements outside acceptable limits, the process or the materials being processed are adapted as quickly as possible to minimize further deviation.
In the Scrum world we say “transparency is value neutral”. That it, transparency itself doesn’t add value. What adds value is what you do with what transparency uncovers. For example, say during a retrospective we discover that as a team we are not very good at working collaboratively. We find that we tend to focus on our own individual work and that we don’t support one another. While it is great to uncover this, uncovering it doesn’t actually add and value! What adds value is addressing this.
If we continue to apply Scrum honestly (and courageously), we experience continual exposure of all our opportunities for improvement, thus offering us the opportunity to become “the best product development and management organization in its market”.
Many companies however falter when it comes to the really important things (for example culture, management, strategy, value) and instead decide to alter Scrum or simply ignore what it is uncovering.
I once explained it to a client as “standing in front of a mirror naked with all the lights on”. You might look at yourself and wonder “how did I get like this?” The mirror isn’t lying to you – it is simply showing you the truth. So the mirror doesn't add value. What adds value is what you choose to do about what you see.
And typically there isn’t a magic solution. It often comes down to drinking less, eating better and exercising. The tempting (and foolish) thing to do is to obscure or alter the mirror until you see what you want to see.
As ridiculous as this sounds, this seems to be the default approach of many companies.
So when does the change end? How long will this “agile journey” be?
That really come down to how agile you want to be. Many people ask “Is the Scrum Master a full time role? And if so, what does the Scrum Master do when they aren’t facilitating the key Scrum meetings?” The question is similar to what I have recently had with some colleagues I am helping. They ask “my client seems to be doing pretty well with Scrum. I am wondering what we are going to discuss at our next retrospective and if they still even need me as an agile coach?” My response is normally something along the lines of “so are you saying that the organisation cannot get any better?”
An approach we applied back in 2010 was to use Scrum for organisational change. Here is how we approached it:
- We developed an organisational improvement backlog. We made it is transparent as possible by using index cards and putting them on the wall for all to see.
- The software-focused Scrum Teams populated this backlog with things they believed the organisation needs to change in order to improve. Typically these come from Retrospectives or from Daily Scrum meetings.
- We established an organisational change team comprised of senior managers who had the ability to make or influence change.
- The Product Owner was one of the Scrum Masters of the software teams that populated the backlog.
- The Scrum Master was the CEO.
- The organisational change team delivered regular increments of change.
- Everyone in the business attended the Sprint Reviews to review progress and discuss the next optimal increment of change.
We used this approach to for on-going programme of continuous improvement. It generated a belief that we could go anywhere and achieve anything. Nothing demonstrates leadership like commitment and action.
So to answer the agile old question “what does the Scrum Master do when they aren’t facilitating the key Scrum meetings” , my standard answer is “improve the organisation”.
How are you going about changing the organisations you work for? What have you tried? What has worked and what hasn't worked?
Note: this post first appeared on my blog agileforeveryone.com.