No one likes change. It’s uncomfortable, difficult, and sometimes down-right painful. But in order to improve and be more effective at our jobs we often need to change. In this industry especially, change happens in technologies and practices at an alarming rate. That might lead you to believe that those who work in this industry happily embrace change and see it as par for the course. In my experience this is often not the case.
“It isn’t uncommon to see an organisation using the same practices and technologies they were 5 or 10 years ago.”
Large organisations want to manage change to reduce the risks it can have. They attempt to have consistency in practices and technology choices, which enable their people to understand what is going on. This allows people to move between teams more easily when necessary, only needing to understand the domain of a new project and not also the tools, technologies and practices of the new team. This has the unfortunate effect of not just slowing down and managing change, but often of stopping it altogether. It isn’t uncommon to see an organisation using the same practices and technologies they were 5 or 10 years ago. In an industry where new frameworks and platforms seem to arrive almost every week, organisations can quickly find themselves using less than great tools for the job, or worse, using unsupported tools. This ironically introduces risks that their behaviour was trying to avoid.
So what do large organisations do to embrace some changes, in the face of a constantly changing industry? How do they navigate their way through the bazillions of tool and language choices to make a sane one, that isn’t just a passing fad? There are two tandem practices that I have seen work in large scale organisations; piloting changes and creating visibility.
Pilot changes by choosing one team to trial the new technology or practice in. At a recent client, our team spent months of talking through the how’s and why’s of Git being a better source control management (SCM) choice than SVN, for the development team of the Fortune 500 company.
Shortly after I arrived, I was introduced to Mike, who was in charge of the internal operations and services team. Mike was responsible for supporting tens of overloaded servers, as well as hundreds of overworked developers. During one of my first conversations with Mike, he asked me what I thought about Git as a source control mechanism. Being a developer, I rattled off the usual suspects: local history, not needing to contact the server for everything, better merge support, and visibility of entire commit histories attributed to the correct authors etc. Also, the developers on the team were dreading working with Subversion, the client’s current SCM of choice, after being burned with merging hell and the lack of visibility of their commit history on other projects.
Eventually, after many conversations, Mike was receptive to the idea of piloting Git in a team. The organisation had already started moving to the Atlassian stack, so another Git selling point was the Stash frontend to Git. Stash allows you to manage your Git repositories, a feature that wasn’t available for SVN. Mike agreed to set up a test Git server, fronted by Stash. Stash would allow him to have a decent UI for access control on top of the Git back-end. It took a couple of attempts, but I was eventually able to import our project into the test Git server, including the fully-attributed commit history.
Once the source control was ported to Git, the team was clamoring to complete the move for our project. The developers had been asking to work with Git for some time, but hadn’t managed to convince the powers that be. I continued to work with Mike on the Stash side of the migration. We were able to set up project information in the web front-end, access controls for multiple projects, and import SSH keys for password-less attributed commits.
After another final export of the Subversion tree imported into Git, our team fully switched over to using the new SCM. I showed the developers how they should import their SSH keys into Stash and then configure their workstations to handle the SSH key-exchange and that was it – they were up and running!
Our team was the first project in this large organisation to fully switch development from Subversion to Git. We were the pilot and thankfully our pilot was a success story. Developers were happier, merging was easier, commit histories were accessible and understood and it wasn’t long before the team was comfortable with the new workflow provided by Git.
It has been 5 months since that initial pilot and the success spread within a few months. Two more teams have successfully carried out a similar porting exercise. Git is spreading like wildfire around the organisation!
“When large organisations face new technology, often their first concern is, how they can implement this change across the board – when it should be to see if it’s viable at all.”
Getting that first pilot off the ground can be hard. It took us months of consulting, getting to know the right people, setting up the right kind of relationships, and doing the right work to affect change in an environment that’s usually very averse to change. The technology change itself wasn’t that difficult. In my experience developers are smart people that can pick up most tools and technologies, given they make sense and are appropriate.
When large organisations face new technology, often their first concern is, how they can implement this change across the board – when it should be to see if it’s viable at all. With some success behind you, you are more likely to understand what is required to implement the change on a more concrete level and some of the pitfalls and gotcha’s that you could meet. Remember, we took several attempts to port over SVN – but you can time-box such activities.
The second part of a change like this is creating visibility. At ThoughtWorks we use the Technology Radar to get a snapshot every 6 months of the technologies and practices we are using in our organisation and at clients. This gives us insight across the organisation about how we feel about them. Should they be assessed, trialed, adopted or should we be more cautious and hold our use? Many other organisations, who want to manage change rather than slow it down or avoid it altogether, choose to adopt a similar radar snapshot for their technology and practice choices.
⁂
When a change is new and it is going well, ensure you celebrate any successes. People are quick to grumble and often forget what is going well. You will need this ‘good press’ to sell further implementation of the change within the organisation.
Remember that not all pilots will be successful. The whole point of it being a pilot is that it is low risk – you aren’t asking the whole organisation to change, just one contained team that you can gauge at any given time of it’s success or failure.