Unofficial Digital Transformations

There're so many people (mostly the suited and chatty type) that bang on about "Digital Transformation" but what does it mean? To them it usually means a big payday and large bill to your company.

Another scenario is that your company may mandate to work in a particular way, leaving you and your colleagues without having any input.

A third, possibly better way is to drive transformation yourself. How far you go is up to you. I call this the "unofficial digital transformation". Ultimately, it's about modernising your processes and tooling without causing chaos.

Before doing anything, a certain amount of analysis and planning needs to be done. You need to think about these questions:

• What do you want to achieve?
• How can you prove it has worked (is there evidence of ROI or other improved metrics)
• Are people happier?
• Are clients happier?
• Are you producing work faster?
• Is the code better quality?
• Is the code more secure?

It can seem overwhelming to do it yourself, with many barriers standing in your way, but it is doable. My team did it. It was frustrating sometimes, but we overcame and just did it one step at a time. You can too.

The steps below show what we did in rough chronological order. The steps are spread over several months as we also had our normal workload to complete and also so colleagues could get used to the changes slowly.

Step 1: Identify what is actually wrong

One of our main issues was the disconnect between our support system, bug tracking, developer tools and tester tools. This was a crazy situation and amazingly wasteful. People used to spend hours reconciling bugs with support cases and producing reports and things like that . Crazy, simply crazy!

First job was to sign up to Azure DevOps and create User Stories for all the big issues. Break down these big issues into Tasks and then you can see what is happening on the Boards.

Step 2: Decide what to measure to prove success

You need to be able to prove that your changes have been successful.  What is success? Your boss might want to see more staff productivity or faster product releases, you and your peers might like to have less schedule pressure or to use more modern tools (who doesn't?) or the company might want to have happier customers or lower staff turnover.

Success is measured differently depending on the point of view.

Step 3: Start Measuring

People don't like change. There are various reasons why ( see https://hbr.org/2012/09/ten-reasons-people-resist-chang ) so measuring their happiness at work is a great way to know how well you're dong as the transformation progresses.

We signed up to https://www.officevibe.com/ which is free for teams based in one location. It sends a short questionnaire every few weeks, the results are then aggregated anonymously and plotted on charts over time. Staff get a chance to send feedback anonymously to managers. This has turned out to be one of the better features. It seems that most people don't like to be candid or honest about how they feel, so having a way to feedback issues was a big hit.

Awesome! Now we can see (a) how people's feelings are changing while we transform and (b) they can feedback what else is bothering them.

Step 4: Start slowly, very slowly

You've got Azure DevOps with your Kanban and workitems of what to do. Now it's time to plan to move code. Before that happens, ensure that the code is fit to be moved. All references are OK, your branching strategy is suitable. At the time of writing, there is a free book "Pro GIT" written by Scott Chacon and Ben Straub and published by Apress available for download.

We decided to move from our old branching strategy to use the more well known and simple Trunk Based Development.

Step 5: Migrate existing work items or start afresh?

Do you move all your existing bugs & tasks or start afresh? It's a big decision. We decided to start a new, with Azure DevOps having workitems added for any new work, and we'd run-down the old bug tracker and kill it sometime in the future when all the old work had been completed and released.

Step 6: Setup CI/CD

Once you're working with Azure DevOps, start to play with the pipelines. Getting code built in the cloud is a sure-fire way to save time and build in quality & security. It's quite easy to do. We did it in about 30 minutes without any knowledge. We could then see the code building in the cloud faster than our development machines could. Fantastic.

Step 7: Improve Security

Some of our plans included using more static code analysis tools (SAST) in Visual Studio. We use Resharper to help find code smells when writing code and we found SonarLint to be a good free tool for SAST.

In Azure Devops, the first tool we added from the marketplace was WhiteSource Bolt which scans code for vulnerable open source packages. It took minutes to plug-in and found some issues immediately which we fixed promptly. This was a bit of a milestone for us as it was proof that what we were doing was right.

Note: This sample image is from the WhiteSource website.

Step 8: Break down silos

It was very strange that our developers didn't really talk to testers, and testers didn't really talk to the people that went on site and released the software. I suppose this is just typical of siloed teams that you get more or less anywhere, but moving to DevOps would mean that the teams would be able to work together seamlessly. As workitems flowed through the system from dev to test the team would finally become one. The new tools would force us to work better together without really having to do anything!

Another benefit is the visibility of work. Everyone can see the progress of projects. Everything is more open and transparent. Things going off track can quickly be seen on the various charts such as the burn down chart.

Step 9: Get bosses involved - with PowerBI

I've always been really passionate about DevOps tools after using TFS in the past and then seeing what Microsoft have done with it to create Azure DevOps. It's not just for techies! Take your generic non-technical managers, project managers and bosses. They just want to know what is going on in brief and maybe have a report every so often.

Getting them engaged is very useful for a number of reasons. If they can see the benefit of what is you're trying to achieve they will help you get things agreed with the bigger bosses, whether it's decisions that need to be made quickly or to get budget sign off or something else. Having senior managers closely interested is useful!

Just tell them that Azure DevOps can show report data in PowerBI and their eyes will soon light up. They've changed the names of reporting to Analytic Views, but it's all the same at the end of the day. Reports!

There are a lot of views already created in Azure DevOps much like there were in the older TFS.

You just link the tools together, choose the view and then start dragging and dropping fields onto the designer. They'll love it.

Step 10: Server Migration

If you're here, you've done well and should be seeing code quality improvements as well as faster product releases, teams working together better and management will be happy, but there's still much more to do.

As mentioned earlier, we had a load of old servers that needed to be replaced. Either we bought new equipment and paid people to look after it, or just get some virtual machines in Azure and pay Microsoft.  They're so cheap, especially when used for Dev/Test and are switched off when not used.  This is an interesting article about using VMs in Azure for Dev & Test.

Next Steps

Our digital transformation is still ongoing, which is why I'm stopping at Step 10 (and bored of writing!)

There's always things to be done, to improve and to get product to market faster. Even the little things we have already done have shown a huge improvement in quality, security and speed. Just keep going and don't give up. Hopefully everybody will be onboard and you'll be encountering  less barriers to progress as you did when you first started out.