Delivering value as quickly as possible is something I’ve always been passionate about. When I worked as a delivery manager for a large Systems Integrator I was obsessed with it. In fact I coined a phrase for it – “Asks-to-Gets” – the time taken from when a customer asks for something to when the customer gets something. I find this conveys the message much more clearly than technical definitions of lead time or long-winded sentences such as “the average time from an approved customer change until the associated software has been deployed into production and accepted by the customer”.
This passion led me to David Anderson’s book on Kanban, and I was struck by a startling statistic: it’s common for teams to spend more than 90% of their time fixing defects. That’s 90% of their time dedicated to fixing something that should have been right in the first place; a huge amount of waste. Clearly reducing this waste is a big boost to productivity – even if you only halve the amount of rework you can massively increase the capacity available for value-add activities, like new features.
Another source of waste is failing to build the right thing. As renowned product management expert, Rich Mirinov, put it: “there’s nothing more wasteful than brilliantly engineering a product that doesn’t sell”. Too much time is spent building features that aren’t part of the core product – a study by the Standish Group showed that 64% of features in most software products are rarely or never used.
Unfortunately, a common response to these sources of waste is to add more, and increasingly bureaucratic, tasks and processes. Organisations try to reduce rework by introducing heavyweight change management methods and planning for several phases of slow, manual testing. They try to improve the chance of building the right thing by introducing additional up-front requirement stages, like analysis and design with all the associated documentation.
In my view, these common responses to reducing waste are often ineffective and, sadly, end up being a third type of waste. Not only do they not add value, they also slow down the end-to-end delivery of features – which only increases the time it takes to get feedback about the product you’re building.
So how do we eliminate this waste?
Kanban
Kanban is a technique for managing software delivery in a highly efficient way. It uses a method of visualising the flow of work to balance demand with available capacity with an emphasis on continual delivery. One of the core practices of Kanban is limiting Work In Progress (WIP). In simple terms this means only accepting an amount of work that reasonably matches the capacity of the team.
As most people would instinctively know, reducing the total number of things a team has to think (or worry) about at any one time reduces stress, enables them to concentrate better, increases quality and reduces bugs.
But additionally, and somewhat counter intuitively, limiting WIP also improves lead times. In some ways it’s akin to the variable speed limits common on busy sections of motorway across the UK, where limiting the speed improves the flow and consequently makes journeys faster.
There are, of course, other aspects to Kanban, and many other benefits too. The more we applied it in practice, the more we got to witness these benefits in action. Suddenly, older, more traditional approaches to delivering software seemed unreliable, unresponsive and wasteful. By contrast Kanban was enabling the teams to focus (making them happier and less stressed) which resulted in higher quality software and, crucially, a reduction in lead times.
It was therefore only natural that when Naimuri was founded Kanban would form the basis for how we manage all our work. In fact, this is where the name Naimuri comes from: roughly translated from Japanese it means “not overburden”. It reminds us everyday to limit WIP so that we can deliver high quality software, reduce waste and minimise the time taken from customer “Asks-to-Gets”.
DevOps
In the early days of Naimuri, all of our clients were in the public sector and our contractual relationship was such that we would develop software, whilst others provided and managed the infrastructure on which it would run. Naturally we focused our efforts on continuously improving the effectiveness of our scope – from the initial requirements through to packaging the software ready for deployment.
As you can imagine, eventually any company will reach a limit with how much they can improve responsiveness, especially without being able to optimize the entire end-to-end process. For software the end-to-end scope isn’t just development – it’s also provisioning the infrastructure on which the software runs, deploying the software and its dependencies, and the ongoing operation, monitoring, and maintenance of it in production.
Fortunately for us, as our relationships with customers have started to evolve and, in particular, as we are starting to work more with private sector clients, we’ve had the opportunity to tackle this through DevOps tools and best practices. From focusing on end-goals rather than technologies, through to the belief that codification is the best approach to automation, DevOps approaches have enabled us to deliver software into production faster and more reliably – achieving a true “push button” deployment.
I believe a key part of the DevOps mindset is a desire to eliminate waste. Rather than achieving this by adding manual tasks and processes, or through extra design or testing stages, it is achieved through automation. This automation enables you to deliver new features into production more frequently, providing you with valuable feedback and improving your chances of building the right thing.
Pairing the DevOps mindset with Agile methodologies, like Kanban, lets you build something in small increments and get immediate feedback about what you’ve built.
This fast feedback loop enables you to significantly increase the chance of building something that will be used and will deliver the intended value.
When I look back at the high levels of waste I was witnessing before, it was a huge frustration for me. In fact it was one of the main things that led to the creation of Naimuri – firmly rooted in the belief that there was a different way, a better way of doing things.
