Organisational Change - Adopting SCRUM & XP

This is an excellent presentation on a company - interenet based - started in 1999, that grew rapidly, had processes that then slowed it down to one major release per annum, and so it adopted SCRUM and XP in its own variant called ADM.

The presentation hints at what it did, what it could do better and so on. The company is called Salesforce.Com. If there is one presentation deck that you should watch with regard to implementing SCRUM then this is the one.

Challenges of Agile Adoption

Some interesting thoughts on how to implement agile. I actually found this very thought provoking. I will watch this one over and over! Can you go too fast in implementing Agile?

Organisational Change - Implementing ‘AGILE’

Wanting to be more Agile is the easy bit. Figuring out how Agile you want to be is a bit more difficult. Choosing the methods you will employ in being more Agile is harder again. But the most difficult bit of all once you have decided which way you want to go with Agile – via creating a business case - is implementing it through organisational change.  The reason being that people hate change. Even if they say they do not, they often do!  Ken Schwaber quotes in his book ‘The Enterprise and Scrum’ a guy at Ford who has pinned the notice ‘Culture eats strategy for breakfast’ to his wall. He got that right, and that is what you need to overcome!

Team Work

When you try and implement change into an organisation you soon find out the fiefdoms, lines of demarcation, boundaries to cross etc that will not make you Mr Popular in a popularity contest. You can persuade yourself that flagging up issues across the organisation such as poor quality, difficulty in building environments, lack of resource at key points in the software delivery chain etc will help – and that you are helping – after all you have found something that needs fixing – that’s a good thing right?  Well, it will help the organisation if the guys on the ‘receiving end’ want to work with you as a team in fixing the problems. If they do not then you have an uphill struggle on your hand and that’s why change must be supported from the top. ‘You are either on the bus, or you are off the bus’ is apt when implementing big changes. A weak central figure required to hold the change team together will result in a weak ineffective rollout, and in an immature organisation the bell may well  be tolling for whose head is going to roll as a result of a less than optimal  change initiative.  I remember a colleague of mine once saying ‘if the King is not strong then the Princes will fight each other’ – and that comment is very true – especially if the Princes are all fighting or plotting to be King sooner rather than later.

You need the equivalent of a Political Chief Whip in ensuring that everyone falls into line to make it a success – otherwise the ‘good guys’ may well get shot in the cross fire and the bad guys get promoted as part of the ‘told you so’ brigade – and that is the end of the rollout, and over time probably the company – a weak and short-lived victory for the blockers to much needed organisational change!

Using SCRUM as a vehicle for Agility

SCRUM is a simple yet at times painful framework for implementing changes. To be successful the process of using SCRUM needs to be supported by a Change team or ‘guiding coalition’ that have four key characteristics as explained by John Kotter in his excellent book – Leading Change. These are

1.    Position Power – key players, e.g. Directors and Functional Heads – need to head off at the pass those left out so that they cannot easily block progress.

 

2.    Expertise – various points of view in terms of discipline, work experience, nationality, relevance to the task in hand and adequately represented across functions so that informed intelligent decisions can be made.

 

3.    Credibility – the team should have sufficient people with good reputations so that its pronouncements will be taken seriously by other employees within Betfair.

 

4.    Leadership – the group needs enough proven leaders to be able to drive the adoption of Agile Software Management practices.

 

Leading Organisational Change

Kotter outlines an eight stage process for embedding change. It is sequential, no steps should be skipped – it is not a ‘pick and mix’. The sense of urgency is a particular favourite of mine – if you don’t have one then you certainly will not have the’ oomph’ to get the organisational change on the road. In order to create a sense of urgency you might want to stress how your competitors are chasing, catching, and want your business space. You might then want to tie in the personal objectives of successfully implementing change to the reward system and so on. The book is well written, easy to assimilate, and the anecdotes alone are worth the money. For a Professor at Harvard he writes like a Journalist on the Times – and that’s a complement to both organisationsJ. The framework is:

1.    Establish a Sense of Urgency

a.    Examine the Market and Competitive Realities

b.    Identify and discuss crises, potential crises, or major opportunities

 

2.    Creating the Guiding Coalition

a.    Putting together a group of people with enough power to lead the change

b.    Getting the team to work together like a team

 

3.    Develop a Vision and Strategy

a.    Creating a vision to help direct the change effort

b.    Developing Strategies for achieving that vision

 

4.    Communicating the Change Vision

a.    Using every vehicle possible to constantly communicate the new change

b.    Having the guiding coalition role model the behaviour expected of employees

 

5.    Empowering Broad Based Action

a.    Getting rid of obstacles

b.    Changing Systems or Structures that undermine the change vision

c.    Encouraging risk taking and non traditional ideas, activities and actions

 

6.    Generating Short-Term Wins

a.    Planning for visible improvements in performance  or ‘wins’

b.    Creating those Wins

c.    Visibly recognising and rewarding people who made the wins possible

 

7.    Consolidating Gains and Producing More Change

a.    Using increased credibility to change all systems, structures and policies that do not fit together and don’t fit the transformation vision

b.    Hiring, promoting, and developing people who can implement the change vision

c.    Reinvigorating the process with new projects, themes and change agents

 

8.    Anchoring new approaches in the Culture

a.    Creating better performance through customer and productivity oriented behaviours, more and better leadership and more effective management

b.    Articulating the connections between new behaviours and organisational success

c.    Developing the means to ensure leadership development and succession

 

So why is using SCRUM painful? Simple – because SCRUM highlights the inefficiencies and critical constraints all along the software delivery chain that hinder software getting into production. You have to stare hard at the realities of what you are confronted with by the teams trying to deliver and you have to act upon them. If you do not, then issues and constraints will get flagged continually – like a stuck record – and you have to make a case for fixing them or not fixing them.  If you choose not to fix the big issues then it is likely your implementation of Agile will fail – and your competitors will love it. If you do fix the issues then expect to see an improvement in delivery times, quality, and cost base compared to your competitors. You will see an improved time to market – and you can compete on the basis of speed. And that means higher profit for your organisation.  However remember to be brave – if you have ever watched the film ‘Zulu’ then expect to come under fire – but hold your nerve – it is worth fighting for.