Guide: Minimizing Waste in Your R&D Organization

Looking at modern software development practices, most of them aim at maximizing the output of your team and the quality of your software. Unless you’ve been living under a rock for the past 20 years you know of the agile development methodology and you’ve probably heard about the lean methodology. Both of these methodologies can be differentiated by a few factors, but they are pretty similar – they aim at delivering fast and to the point. These methodologies are heavily influenced by the Toyota Production Systems (TPS) which have revolutionized modern manufacturing processes.

You can perform better by looking at things that are broken and try to improve them ala Toyota’s Kaizen. But you can also ask yourself: what is your team wasting time on? What is my team’s Muda? Worry not, for we have the answer. The “Muda” is that wasted time on unneeded code, features that no one uses, and it’s also your over-engineered future proofed code.

What isn’t waste?

To better understand how you can reduce your team’s waste, you can begin by trying to define what isn’t considered waste. In agile methodology, the standard is continuously releasing software. Whether you’re Scruming or Kanbaning – you aim to release fast. The goal is to work closely with your customer and receive feedback on everything that you develop for them. When you deliver something to your customer and your customer wants it – that definitely is not waste. But what happens when you deliver a new version to your customer and they don’t want it? Well, that pretty much is waste. And even more so, that’s not only a waste of your time, but a waste of your customer’s and a waste of the code that’s been written. 

Defining a deliverable

A common definition used in both agile methodology and software development is the “deliverable”. A deliverable is a product that you can and need to deliver to your customers, mainly focusing on the value it gives your customer. A product (or a version) that you deliver to your customer, which has no value to your customer, isn’t a deliverable. Once you focus on working and developing only deliverables, your waste will be drastically reduced. When I look at a deliverable, I try to look at the parameters with which it should comply with:

1. Customer value – The customers use your product (and hopefully pays for your product too) for a reason. They perceive the product as something that benefits them and which gives them value.
2. Product strategy value – Your deliverable must help you understand how to develop your product better.
3. Infrastructure value – Toyota might refer to this as “Nemawashi”. Laying the foundation for a change, or making a change possible in the future.

Each and every deliverable should create value for each of these 3 parameters.

Customer Value

This parameter is the easiest to look at and define. As I’ve mentioned, if you release a software version that your customer doesn’t perceive as valuable, they won’t install it, download it, and most importantly, they won’t give you any feedback about it. If you made your customer’s life better with your delivery, then that delivery isn’t a waste.

You might try to tell yourself, “Hey, what about if I fix a bug?”. Well, does that bug affect the customer? Did they experience any issues because of it? If the answer is yes, then they will perceive it as valuable. But if they didn’t experience any issue and that bug didn’t affect them, why bother them with it? If the customer will need to install or manually upgrade, they will never do it.

Let’s take a look at a simple example: your team has discovered a bug that causes an overload of resources in your backend and since you have autoscaling it doesn’t affect the user, but it affects your cloud costs. You can fix the bug, but your customer won’t upgrade. For the customer to upgrade you will need to add a new feature or improve something in your product in order to motivate the customer to upgrade.

Product strategy value

This one is pretty easy to ignore sometimes. When we develop our product we can sometimes be short sighted. We look at the current feature being developed and use all of our resources to make it happen. We often want to win the battle we’re fighting and not think about the war and our next steps. Looking at your product’s backlog, you will see a bunch of features that you need to develop next. Do you have all the data needed in order to understand how those features will look like? At what scale do these features need to handle? How will users know that these features are there? You can collect data and prepare in advance to your team’s next tasks. Start collecting this data now, add logs, add metrics, add mockups – add anything that can give you feedback on your current features and your future features. If you don’t collect this data, you’ll go blindly into the dark when you start developing your next features.

Infrastructure value

When you look ahead at your software’s upcoming challenges, you can usually tell that you’ll need a better infrastructure. You will be able to understand this sooner if you collect data when working on your deliverable’s product strategy value. Some tasks can’t fit into a two week sprint, but that doesn’t mean that you won’t create deliverables when working on them, though you will lay the foundation and start working on them while still delivering other deliverables. When managing developers, you often hear them saying “We can’t do this, we need to delete everything and start from scratch”. Starting from scratch is usually not possible, but there is an alternative: to rebuild or set your foundation brick by brick along your day to day tasks.

Try, as much as you are able, to set your foundation and improve your infrastructure one step at a time. Do this while continuously delivering new features in order for your future features to be achievable.

Measure your deliverables

When you plan your R&D roadmap, try to measure your deliverables. How many of your deliverables don’t provide value to your customers, product strategy, and infrastructure? A good balance of deliverables creates value to all three parameters and will reduce your waste, making sure you are always focused on the right path, ensuring that you will write less code that is thrown away and your team will be much more prepared for your future challenges.

Rookout can be used anytime in order to collect data and thus help you achieve your product’s strategy value. By enabling your developers to get the data they need, they’ll be able to focus on what your customers find valuable instead of wasting time on unnecessary features or code. No more waste, just more value-creating features.