In the real world, time and budget are limited on every software project. So it is important to implement software in high productive, yet sustainable manner. There are many aspects that are important when you want your team to deliver twice the value in half the time. This post focuses on the aspect of waste control when building new software. Waste monitoring and reduction are key to get to high productive software development. Your team should always be on a lookout for obvious and more hidden waste activities that make projects fail the timing and budget constraints.
Highly productive teams are conscious not to burn resources on activities that do not add value to the system-under-construction. These are some guidelines how to mitigate different types of waste that are often overlooked during software endeavours.
Do It Right the First Time
This is all about implementing the right features the right way.
Building the right features implies that the product owner always wants software features that deliver the most business value for money at that moment in time.
Consider it a red flag when your project first implements CRUD screens for reference data. Instead you should expect early software increments to deliver core features such as calculation engines for a salary system or buying books for an online bookstore. Additionally many agile projects still have a kind of big upfront requirements activity that defines a scope fixed in stone. In such a setting, stakeholders tend to over communicate requirements as the do not want to miss a features deemed important by a colleague.
Humans in general fail dramatically at knowing all details upfront. However, we are good at discovering details step by step and learn as we build up complexity. When your product owner’s major focus is to stick to a fixed scope, the red flag goes up. The job of the product owner should be a quest to deliver real business value as early as possible. The investigation of business and feature requirements should be done with enough depth so that a specific feature should not be built a second or even third time.
Building features the right way
Think before you build. It is very important that the domain layer is carefully designed. Domain models that really match up with your business reality will help you to avoid expensive rework. Make your domain models and domain glossary explicit and understood by all developers and business stakeholders. If one model matters in systems architecture, then that would be without any doubt the domain model.
When you make a mistake, fix it right away. Stop everything else and address it. There is ample research that demonstrates that fixing bugs later can take more than twenty times longer than fixing it immediately.
Reality is often that testing features happens 1 to 4 weeks after implementation. Fixing bugs that late burns project resources that can no longer be invested in valuable features. Therefore it is very important that the software increment corresponding with a user story is promoted as soon as possible to the test environment. The product owner (or a delegate) tests that the implementation meets the requirements and has no bugs. The team fixes functional or technical issues before everything else.
Ensure flow
Good flow has two aspects. Influx and throughput.
The influx of requirements sometimes gets interrupted. Missing consensus on core requirements amongst stakeholders are often a reason.
Another is missing or unavailable stakeholders with key business knowledge and decision power.
When influx of requirements is interrupted, teams usually work on the removal of technical debt. Once technical debt has been sufficiently removed, then the team will try to keep itself busy in a useful manner. Despite of the team’s best intention in doing so, this will most of the times lead to burning project budget in an unproductive manner.
The adopted development process should be the simplest possible, the smoothest, the most trouble-free way to get things done. Remove all steps that that do not add to the value of the software. Guidelines should be downsized to only describe the conditions that must be met to allow a story to be moved to the next step in the flow.
Good retrospectives will streamline your process and guidelines. If they do not, then reconsider the retrospective format you are using. Waste activities and waste guidelines burn resources that can no longer be used in value creation. So get rid of them.
Do One Thing at a Time
Doing more than one thing at a time makes you slower and worse at both tasks. This is true for working simultaneously on different projects, but also for multi-tasking within one project.
This chart appears in “Quality Software Management” by Gerald Weinberg. One of the classic works on how to develop software.
It shows the amount of time wasted on project context switching in function of the number of projects over which to divide attention.
Harold Pashler demonstrated in the early 1990s that this also applies to simple tasks. He conducted a few simple experiments. He would have one group do one really simple thing, say press a button when heard a sound. And then he would give another group that task plus another simple one, like pressing a different button when another sound was produced.
As soon as another task was added, no matter how simple, the time involved doubled. Pashler theorised that there was some sort of processing bottleneck—that people can really only think about one thing at a time. He reckoned that a certain amount of effort is involved in “packing up” one process, reaching into your memory and pulling out another, and then running that job. And each time you switch tasks, that process takes time.
The “Loss to Context Switching” column is pure waste. Thus be conscious of the cost of context switching. It’s very real and you should try to minimise it. If you think this doesn’t apply to your team, you’re wrong — it does.
Working Too Hard Only Makes More Work
Working long hours doesn’t get more done; it gets less done. Working too hard work for a longer period results in fatigue, which leads to errors, which leads to having to fix the thing you just finished. Teams should only work weekdays at a sustainable pace. Rather than work late or during the weekends.
Scott Maxwell introduced scrum at OpenView. Their corporate culture expected that people would work late and on the weekends. These were aggressive, ambitious people. But they were getting burn outs, depressed, and demoralised. Many great co-workers could simply not take it and just quit.
The y-axis is productivity and the x-axis is hours of work. Scott noticed a shift in productivity. Working more hours stopped producing more output.
He measured performance on different open view projects and came to drew the following curve. The peak of productivity actually falls at a little bit less than forty hours a week.
Takeaways
When you want to get to highly productive software delivery, many different aspects are important. In too many projects, waste consumes a significant portion of the available resources. Waste really is a deathly sin !!
How can you reduce waste?
Do It Right the First Time. Build the right features the right way. Test and fix immediately. Only then is your story done. Ensure flow. The team may not become idle due to insufficient influx. The flow should be effortless. Thus remove all steps and policies that do not contribute to valuable software. Do One Thing at a Time. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does. Work hard, yet at a sustainable pace. Working long hours doesn’t get more done; it gets less done.
