Three factors affecting your agility
Let’s talk about cakes and baking. It’s similar to making software. No really! How quickly you can bake a fantastic cake depends on three main factors. Turns out, it’s the same three for software.
In essence, agility is about your ability to respond to change. I can gain a competitive advantage if I can update my software quickly when I see an opportunity in the market. As a software developer, I’m going to work together with other professionals to decide what new features to build at any one time. The important question is, when we’ve agreed on a particular change and realized the cost of delay is significant: how quickly can my team and I make this change?
Allow me to answer that question by comparing it with baking. How long does it take to bake a cake? As with software, I think there are three main factors.
The first factor is how complex a cake it is. How many layers? How many kinds of filling? How fancy will the decorations be? Similarly, changes to a piece of software vary in how big and complex they are, and that will affect how long they take.
The second factor is the skill of the baker(s). When you make fancy flowers out of sugar paste how convincing are they? Can you whip cream without it turning into butter? Do you know how to use a thermometer to get perfectly thick and creamy egg custard? If your skills are poor, you might need to throw out your first attempt and make a second batch of custard or cream or flowers, which obviously slows you down. Developing software is similar - skill, experience and knowledge of particular tools all come into play. If your code changes are poorly designed and fail the tests or the code review, that can similarly slow you down.
When baking, the next major factor for how long it will take is the kind of kitchen you’re going to work in. If I’m a contestant on a show like Bake-Off, I will have a sparkling clean workbench and all the gadgets and accessories I could possibly need. Dirty bowls and saucepans vanish as if by magic when the camera is turned the other way. Fantastic mouthwatering creations appear in a very short space of time.
In contrast, if I’m at home, I might need to clear a space on a worktop before I can start. I could waste valuable minutes hunting around for an electric whisk attachment in an overfull drawer. I might belatedly realize my cake tin is too small for the project I have planned or that I set the oven to the wrong temperature. Creating that amazing cake is not going to be as quick and smooth as it could be.
The worst conditions for baking that I’ve experienced were probably in my shared student house at university. Not only were accessories like whisks and cake tins hard to come by, a huge pile of dirty dishes obscured the sink most of the time. After some weeks, we discovered one of the third years had decided his final exams were so important that he had started to leave all his washing up “for the first years to take care of”, as he put it. I hope you don’t have anyone like that on your team!
In the same way, how long it will take you to build a feature will depend on the state of the environment you’re working in. For a software developer, that environment includes not only the build tools and programming language as you would expect, but also the state of the existing code. Is it clean and easy to understand? Is the current design amenable to the planned change? You might need to spend time cleaning up and fixing things before you can start.
There’s also the build and deployment pipeline the team has set up. Are the regression tests quick to execute and generally passing? Is the deployment automated? Can I observe logs and find bugs in production? If that infrastructure is well oiled and running smoothly, it will make a big difference for how soon my software change can be rolled out.
If you want to be really agile, you need to consider how to improve some or all of the factors in this equation. If you want to build complex, valuable features quickly, you need to make sure you have developers with the skills to build them. You also need to invest in the “kitchen” they are working in.
When I consult with different organizations, I often see problems with developer skill and poor development environments. Investment in both can lead to big gains in agility. You want the time to market for a new feature to be dominated by the essential complexity of that feature, not the accidental complexity that comes from poor code quality, testing and deployment automation. Coding is like baking. Working in a mess is not agile!
Acme Corporation is a famous software company employing around 2.000 developers. Like many other companies out there it has ensnared its faithful employees in a devious plot. It is murdering them, legally and out of sight, by wasting their time.
The human case for acknowledging and measuring wasted time
Continuous Integration and Code Review are strongly correlated with success. Many use Pull Requests for code review, but for co-located teams this can be an obstacle for CI. Is there a better way?
A short story about Pre-tested Integration
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Learn how Docker and Kubernetes work and the key benefits they bring. Using real demos, I show how Docker is a great packaging and distribution technology, and how Kubernetes provides a powerful runtime for containerized applications.
Watch this introduction to Docker and Kubernetes at the Trondheim Developer Conference (TDC)
In the world of Agile and DevOps we use many figures, charts and diagrams to argue and reason about our world and how we prioritize and make choices. However, at all levels of the organization, we misuse and misinterpret figures. It’s time to be explicit, measure the right things and act on them. Watch this talk from DevOpsDays Zurich in May 2019.
Watch this talk from DevOpsDays Zurich
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps