Do Governments Need to Digitally Transform?

Let's play devil's advocate here and assume that governments do not need to undergo a digital transformation.  What could possibly go wrong:

• Customer service never improves and citizens become dissatissfied with services.
• People hate using government services because it forces you to things the old way...like before the smart phone.
• Apps are old, slow, unreliable and unpatched.  Sounds like a dangerous attack vector to me.
• Taxes are constantly going up, whilst service quality degrades.
• People become so disillusioned they look at alternative strategies.  Potential riots, civil unrest, or worse still they vote in someone with no political experience.  Maybe Trump!

That's exactly what you're seeing around the world...and the result is that government's are themselves being disrupted.  We're seen it in the US, exacerbated by Russian interference in the US election.  We're seeing it play out with Brexit, as the UK moves away from the European Union. 

I'm going to pull in a number of learnings from 2 courses I run:  DevOps Foundation and Leading SAFe.  Click on the pictures below to see the course outlines:

I believe those stories are just the start.  So what can governments do to prevent these extreme forms of disruption.  Well....there are two weaknesses that need to be rectified:

• Be serious around removing technical debt and upgrading systems.
• Embrace change and not resist it.

There are many ways to overcome those 2 achilles heals....here are 3 methods to help:

Understand who your customer is?

This involves understanding the key steps of the high-level process.  From our first client interaction to when a product or service is delivered and value is consumed.  We call this a value stream:

More importantly.  Everyone in your organisation needs to understand who the customer is.  Not just the people at the end of the value stream, but change their mindset when dealing with their colleagues.  

A customer is someone who consumes your work.  So if you're a System Architect, the System Engineers consume your work and are therefore your customers.  If you are a project manager and you have to produce executive reporting, those execs are your customer.  If you're a SCRUM master servant leader, then your dev team are your customers.  If you're a developer your testers are your customers.

By shifting your mindset to a customer focused mentality, it will force you never to compromise on quality and your customer at the end of the value stream, will have the best possible experience.  Here is some more guidance for further thinking:

Make Yourself and your work Visible and Transparent

That means open yourself up to criticism and learning.  Be open and honest in your communications.  When you author a document, make it clear you are the contributor, so that people can reach out to you and discuss the content.  Some of my most fantastic opportunities in life, have come from being visible and transparent.

Other forms of transparency include:

• Writing blogs for both internal and external consumption.
• Open sourcing your code and ideas.
• Creating newsletters for clients and stakeholders to keep them in the loop on progress.
• Share all your work with your colleagues.
• Aim to share your work with key partners.

There are some great techniques / practices from Agile software development that can also aid transparency:

• The use of Kanban boards to show how work flows through a system.
• Product Backlogs show all the work that needs to get done.
• Linking your Epics to your Features to your Stories to help with requirements traceability and budgeting forecasts.

Here is a great article on how you can use a Kanban board to show the flow of work through your continuous integration / continuous delivery pipeline:

I have 5 more practices that can help governments too.  These include:

• Empowering your people.
• Creating fast and effective feedback loops.
• Demonstrate secure, working software every 10 days.
• Assign funding to the value stream, not the project.
• Decentralise decision-making.

But I think those can be covered in a future blog.