Tuesday, 26 November 2013

Switch in Action: Business Change Management Applied to Software Engineering

As regular readers of this blog would know, I recently read Chip & Dan Heath's Switch (which I blogged about here). One Saturday evening in July, whilst only a short way though the book, I found myself thinking of the challenges we had rolling out "Trails", our automated deployment tool. Even though Trails was built by our System Team, using agile methods, including fortnightly demonstrations of working software, the roll out was far from smooth. Would we have been more successful if we had used the Switch Framework? Switch argues that for change to be effective you have to Direct the Rider (our rational side), Motivate the Elephant (our emotional side) and Shape the Path (clear the way).

A few months later, the System Team had another change ready for implementation. This time we would be changing the EDW source control repository from SVN to Git. Given the experience with Trails, the System Team made a huge effort to get buy in from the impacted teams. They spent countless hours at the whiteboard talking with teams about why version control is important and how version control will enable better data in development environments. There was some resistance, strangely enough because some engineers thought the proposal was to replace SVN with a bespoke in house application called "GIT"! The conversation improved significantly once everyone got on the same page. To use the metaphor from Switch we had started by appealing to the developers rational side, the Rider, by Pointing to the Destination: Change is easier when you know where you’re going and why it’s worth it. 

As the cut over grew closer, the System Team, using their new found "Jean Tabaka" skills, scheduled a workshop to plan the change. They had learnt from the Trails roll out that no amount of PowerPoint or documentation would make a difference. What had worked last time was sitting with the engineers while they tried to execute the new process and helping them. If Switch was to be believed, we should:  "Follow the Bright Spots. Investigate what’s working and clone it."

Replicating this approach was not as easy as it would seem at face value. With Trails the change was less invasive, only impacting the engineers executing a given deployment. A member of the System Team could sit with the engineer each time they needed to use the new deployment tool until they were comfortable. With Git, we needed all six teams to make the change at once. After coming to the realisation the System Team were not Gremlins and could not be multiplied by adding water, a different approach was required.

In the days leading up to the planning meeting, EDW Development Manger, +Wayne Palmer had been giving a lot of thought to the roll out approach. His original instinct was to include all the things that "we just had to do" in the scope of the change. The theory being that the engineers were going to have to use a new tool anyway, so they wouldn't know the difference. Thankfully his train of thought eventually lead him to refer back to Switch. He knew his instincts were wrong, we needed to: Shrink the Change. Break down the change until it no longer spooks the Elephant.  He talked to the System Team Product Owner about the magnitude of the change. They discussed their hopes and fears for the upcoming deployment and decided to defer the major change to the current branching strategy, continuing with branch by project rather than moving to branch by feature.

Even with a smaller change we were still going to need more support than the three System Team developers could provide, if we were going to be successful. Again using the advice from Switch, Wayne suggested we look to increase our pool of subject matter experts by growing our people: Cultivate a sense of identity and instil the growth mindset. Each team was asked to nominate a Git Champion that was passionate about the change and respected by their peers. The System Team then partnered with the "volunteers" to define the process that would be used to migrate the non-production code from SVN to Git.

The change was deployed one Sunday a few weeks back and to quote the System Team Lead Developer "It went scarily well". That is not to say we have not had some hiccups since.  Last week someone accidentally deleted the master branch in order to overcome a merge conflict, by using an SVN technique as opposed to a Git technique. Thankfully these types of errors are easy to back out with Git!

All things considered, the concepts we used from Switch lived up to their promise. I do think we missed a trick when it came the third component of the Switch Framework - Shape the Path. While the hiccups we experienced have not been catastrophic, with more focus on ideas like building habits they might have been avoided completely. So next time you are looking to change the behaviour of your software engineering team don't forget:
For things to change, somebody somewhere has to start acting differently. Maybe it’s you, maybe it’s your team. Each has an emotional Elephant side and a rational Rider side.  You’ve got to reach both. And you’ve also got to clear the way for them to succeed.            Chip & Dan Heath 
To hear the full story of our journey towards DevOps watch the video of my keynote at the DevOps Enterprise Summit 2014.



Tuesday, 12 November 2013

Measuring Team Happiness

When I accepted the role leading the EDW delivery team, I knew my biggest challenge was going to be customer engagement. I had been a customer of the team for a number of years and I am sad to say I would not have recommended their services to anyone. Now the tables had turned, I was the head of the organisation and I had to change the business perception of our ability to deliver if we were going to survive.

It is a little known fact that I used to work in Market Research. My portfolio included Brand Research, Customer Satisfaction Research and the occasional Employee Satisfaction survey. Given my background in Customer Research, naturally my curiosity was peaked when my employer moved from measuring customer satisfaction to implementing the Net Promoter System (NPS).

For those of you not familiar with NPS, it is a customer loyalty metric, developed by +Fred Reichheld and Bain & Co. NPS is measured by "the ultimate question": "On a Scale from 0 to 10, where 0 is not at all likely and 10 is extremely likely, how likely are you to recommend [Company Name] to a friend or colleague?'. Responses are categorised into Promoters (scores of 9 and 10), Passives (scores of 7 and 8) and Detractors (scores of 6 or less).  The percentage of promoters minus the percentage of detractors is the Net Promoter Score.

Source: http://netpromotersystem.com/about/measuring-your-net-promoter-score.aspx

I was not aware there was a whole book on the topic until +Mark Richards mentioned he had been reading the book behind the Net Promoter System, +Fred Reichheld's The Ultimate Question 2.0. So of course I followed suit. While the book gave me quite an extensive list of ideas to follow up the one message that spoke to me the loudest was that "You can't create loyal customers without first creating loyal employees." or as I like to phrase it "happy teams lead to happy customers". The Ultimate Question 2.0 uses Apple Retail as a case study, citing a correlation between stores with high customer NPS scores and employee engagement scores and vice versa.