Decoupling your technology from your IT

In my last article I discussed the differences between IT and technology projects and the problems that arise from treating one like the other. Now we have a framework to identify the differences, we can start to look at how to decouple our technology projects.

How many times does your organisation deploy in a day?

For our technology projects to be competitive and successful we need to be agile in our delivery model and adaptive to the changes and environment that we sell into. We can not be stuck behind release schedules that are months or years away. Building a resilient organisation that can adapt to change quickly is more important now than it has ever been.

In 2018 Nicole Forsgren and Jez Humble released Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, probably one of the best technology books I’ve read in the last ten years. Over four years they surveyed hundreds of companies to establish what makes a company high performing. I won't spoil the book as it’s a great read and a must for any Engineering Manager, but the overriding conclusion was simple, the organisations that were high performing were those that could adapt to change quickly.

In 2014 Werner Vogal (Amazon CTO) wrote a blog post about the Amazon deployment engine Apollo and how it did 50 million deployments in 12 months to dev, test and production. That is 1 deployment each second.

Deployment frequency is a fantastic measure for technology performance as a high frequency of deployments requires well established DevOps tooling, processes and culture and an organisation that can define and package change into small increments. In Accelerate, deployment frequency was identified as a key metric for measuring performance and is included in the 4 key DevOps metrics measured by DevOps Research and Assessment (DORA).

Focusing back in, although our IT projects would benefit from the same principles and approaches, the focus here is our technology projects. The goal is not to achieve a date when a technology product ships, but to build an organisation that can ship technology change continuously, then refine and optimise those processes to maximise the value of the product that has been built.

We already know all the tools and techniques that are required for setting up our delivery engine for success: Agile, MVP, Kanban, Continuous Integration, Continuous Delivery, Automated Testing, DevOps and Cloud Infrastructure. But in doing a transformation we often don’t set up the measurement KPIs that enable us to monitor and continuously improve our delivery organisation.

An improved delivery model can react better to feedback and therefore ship better products, but these methods by themselves do not solve the problem of shipping better products.

When is a product done: An Amazon analogy

The Lean StartUp (published over 11 years ago) was the first book I read that managed to take all the emerging practices in software development and wrap them up into a narrative that actually made sense to the business at large. Unfortunately its lasting legacy is the Minimum Viable Product (MVP). One of the most over used and misunderstood terms in business today. MVP has become interchangeable with v1, or “Whats the worst product we can launch and get away with” - Tim Loo, this is wrong.

Amazon can be regarded as one of the best product engineering organisations today, yet despite all their successes they have also had failures. Viewed another, more charitable, way could they be characterised as learning events that made them better and stronger? As a consumer of AWS services it’s hard to keep up with just how quickly they can launch new products and iterate them from ok, to good, to great.

When AWS first launches a new service it’s their MVP, it’s often free and very limited in its features and can be a poor experience. They offer no SLA and acknowledge that things may change.

As of this today the AWS App Runner service, a serverless solution for hosting and running APIs in a fully managed environment, only works with Github (owned by Microsoft). It will not pull code from Amazon’s own code repository product Code Commit. It seems absurd that I can’t use Amazon’s own code repository service to host and deploy from, but I can only presume that the App Runner team wanted to tap into the largest community of software engineers on the planet, and they live on Github. Being feature complete would mean AWS supporting other code repositories e.g. BitBucket and their own. But they have prioritised other features instead and did not delay the release to be “feature complete”.

The tradeoff that the App Runner team have made highlights just how focused they are on shipping early, tapping into the largest customer pool and minimising the amount of code to exactly what is needed to onboard their target users and start testing their solution in a live environment. How can they do this with confidence? Because they know they can release software often.

A seismic shift in software development

This marks a significant shift in the software development industry. There was a time when releasing software was expensive, and the cost of change was high. There was little optimisation of our processes and organisations to make them fit for change. In fact, we did the opposite. We designed our organisations to resist change as it represented a risk to the business. In those days, there was a focus on making sure we designed things right first time.

But now I can build an experience and ship a product in days and then continue to iterate and experiment with minimal overheads. How does this change how we build digital products? What short cuts can I take to get to early validation points?

We can do all the research and testing of prototypes in the world, but nothing beats uncertainty like that first customer signing on the dotted line for the product.

The narrative central to The Lean Startup still rings true, but now we have the tools and the processes to really adopt the practices Eric Reis exposed in his book. We need to change our mind set and think about our solutions as products, with a relentless focus on risks, experiments and being data driven.

So, how do we decouple our technology projects from IT?

In my many years in technology, I have seen countless trends, fads and ways of working come and go, but the fundamentals of how I build digital products and services have not changed. It does not matter if it’s a side hustle, a startup or a new offering in a global enterprise. The principles are the same.

• Focus on reducing the cost of change: Build your deployment pipelines and automation from day 1 and ship to production a hello world app.

• Think big, but act small: Build the smallest possible piece of functionality and ship it.

• Build right first time: Don’t think MVP means poor quality. The M is for minimal, as in minimalism, that means minimal features, not minimal work.

• Think products, not projects: Products don’t have a start and end date, they have a lifecycle. MVP, rapid iteration, market fit then scale. Each phase of the life cycle requires a very different focus, but the principles are the same.

To get started it must be accepted that technology projects have different characteristics and need to be treated differently. Then we need to adapt the organisation so it’s optimised to ship change regularly, reliably and repeatedly. Finally, we need to start thinking about the projects as products. Not things that have a start and an end, but as an idea that needs to incubated, rigorously validated until data from the product can start to be used to validate the business case and then scaled, refined and optimised. This is a journey that if done well can deliver massive benefits to your organisation.