Coding software is no easy task. It calls for similar unique requirements as other businesses, but is also technical in an exclusive way that is different from other models. A successful software project is the result of excellent coding skills that most people on a team cannot understand fully. Also proper management, planning and cooperation are needed.
Therefore, to reach the goal of a software project, you must identify areas where inefficient parts of the process are occurring; these are sometimes obvious and sometimes very technical. Watch our video to get a grasp on reducing the unnecessary aspects of development that hinder productivity.
Video Transcript:
Seven types of waste
There are seven broad types of waste in software development that we’re going to talk through:
- hand offs
- work in progress
- over engineering
- task switching
- delays
- relearning the process
- defects
As we go through them, you’re going to notice that there is, at times, a reasonable amount of overlap between. You maybe be able to think of a specific example in your projects where there is a bit of blurring between them at times. But these general definitions will cover pretty much everything you’ll encounter in your projects.
Before we begin, a word of warning: Waste is an intrinsic part of projects and processes. Some types of waste in software development are there as a result of a deliberate decision you’ve made. Waste is not a thing you should be approaching as abhorrent. You shouldn’t be thinking, I must remove all waste from my project. Everything needs to be looked at as a cost benefit analysis. Why is this waste here and is it more beneficial for it to be here?
1. Hand offs
Hand offs is the waste involved when a task has to be handed from one worker in a process to another. The new person has to get up to speed on what is happening in the process. The typical example when it comes to software development is the development of a feature.
Here we’re going to come to that concept of built in waste.
Unless you’re having your software project being done by a single individual; where you just give them the requirements, they do all of the design, they do all of the development and all of the testing and then give you the end result; there are obviously going to be some hand offs. Maybe they’re going to start off having a BA doing some analysis work. Then it’s handed on to the next person who does some development work, then it is handed on to a tester to test it. Every one of those hand offs obviously brings in some waste in software development.
In many cases we don’t want to avoid that, but there are cases where you might give someone a task that is too big for them to finish before they go on leave. At the point that they are 80% through the task, it is time for them to go on leave. They need to hand something over to another developer. That developer now needs to come up to speed with the whole process, everything that has gone before, in order to continue just doing the 20% of the work.
So when it comes to hand offs, you want to look at your system. Work out ways to optimise the amount of hand offs that there are in the system while still getting the benefits of the hand offs that are there.
2. Work in progress
Work in progress is pretty much the most prevalent form of waste, but it is one that is really easy to tackle. Work in progress is work that has been partially or in some cases fully completed, but not sent live. Until the point that it is sent live and it is sitting on your web page or on your product and the customer can engage with it, it’s adding literally no value. You’ve spent all the money potentially but it hasn’t given any value.
So the main example of work in progress is if your software process doesn’t have a defined go live step, you can end up with a lot of material that even through inattention, people haven’t realised this thing has not been sent live. You can end up having spent the money and developed the feature but no one has realised that feature has not actually been generating any form of value. So work in progress is an easy one to tackle just by keeping track of the tasks you’ve got around and making sure that everything you’ve done has been properly delivered.
3. Over engineering
Over engineering is doing more work than was required to achieve a specific outcome. The heart of beating this form is active cost benefit analysis of a feature. A great example for this one is say you’ve got a sign up form that you want to implement on your site. You’re trying to collect the name, email address and telephone number of people who are trying to purchase from you.
At its face, that is a pretty simple operation. But you might decide, I want to make sure that every email I get is a valid email. I don’t want to waste time with people who give me rubbish emails. So you ask your developer to put in place verification that checks the email and makes sure that the email address is valid. They spend a few hours putting regular expressions in place so that someone can no longer put in an incorrect email. Had you not done that work, it’s entirely possible that 99% percent of your leads would have given you valid email addresses anyway. So you’ve spent some time to overcome a problem that was never going to be a problem.
Premature optimisation, Ben talked earlier about the dangers of optimising before you’ve found there is a problem. Over engineering is exactly that. It is deciding to go too far before dipping your toe in the water and discovering what the actuality is, getting some data into the system to tell you what you need to do.
4. Task switching
Task switching is a tough one. It is the battle between responsiveness and efficiency. You’ve got a developer and they’re working on a cool new feature. They’re working on it and all of a sudden a client of yours sends you and email and says there is a problem. I can’t log in, I can’t do task x, y or z. You say immediately, that is a problem and because the person has contacted you, you’re instilled with an urgency. This thing must be dealt with. Often you don’t stop to think is this something that is occurring for everyone? Is this something that has more benefit than the thing the developer is currently working on?
You tap the developer on the shoulder and say, please deal with this thing first. The developer dutifully puts aside what they were doing, picks up the new task, resolves it, tries to go back to the next thing. Another email comes in. The cycle continues. Every single time the developer breaks from what they were doing, there is, I think this has been studied, twenty minutes of loss as they get themselves out of the mindset they were in, delve into the new context of the new problem and then swap back.
Every single time you interrupt someone and make them swap from one task to another, you’re introducing waste. So you really need to think, is the problem I’m solving something that could wait a few hours? Is it going to be the end of the world or can I just let them finish the thing that they’re doing and then make the change?
5. Delays
Delays is another one of those types of waste in software development that is not necessarily bad. Delays is the waiting between the end of one process and another. It’s an indirect type of waste with often an impact on elapsed time. Say you’ve got a shared tester working between a variety of projects. You have a developer who has finished their task. The task is now ready for testing and that shared tester may not be available. Now there is a delay while that shared tester can pick up the task and continue the process.
That means that feature temporarily becomes work in progress. So depending on the nature of it, you have to deal with the amount of time the feature is not in the market. There is a cost there. Delay is something that can be addressed but at the same time you have to set that against the cost of having a tester who is always ready to pick up the next thing. There is an optimisation to be had there as to how much delay you can take out of a system.
6. Relearning the process
Relearning the process is needing to get back up to speed on a piece of the system that hasn’t been looked at for a while. This is a similar type to task switching in that every time someone has to engage with a piece of your system, particularly a developer, they have to get themselves into the context. It may be part of a system you deal with on a daily basis but for the developer they may need to understand how it actually works behind the scenes and the broader context.
Every time they do that, again, just say you start with your registration form. Two weeks in you decide you want to add a new field, you want to capture someone’s address. So the developer goes and implements an address field. They then don’t do any work on that for another few weeks and then you decide, I want to change the address field or add a suburb to that address field.
Back in they go and they have to relearn how that thing works again in order to start working on it again. You do that over the course of six months and you’ve actually put waste into the system. You’ve had them engage in this piece of the code again and again. If you had batched all of those up, and this is where you have to look at how important the feature is right now, if you batch all of the features up and get them to do it once, you’ve reduced the waste overall. They’ve just engaged with the system once, done all of the changes together, put it live and now they don’t have to deal with it again for a while.
7. Defects
Defects is the fun one. Defects arise in the code itself. Defects arise for a number of reasons.
- Processes not followed. You may have had a testing procedure that wasn’t followed.
- A spec may have been misunderstood or not followed. You might miss something working across multiple documents, for instance, you don’t see a requirement.
- The spec may have been insufficient or incorrect. Sometimes the people making the specs make mistakes.
- You may have an indirect effect on codes that already existed. So you’ve made a change to this part of the system and it turns out that it also affects this part but you haven’t noticed it and now you’ve got a bug.
- Then there is just plain old human error. Sometimes people make mistakes when they’re doing work.
The difficulty with defects is, as Ben said with the NASA example, you can spend infinite amounts of money trying to deal with defects. Defects is one of the big ones where you want to spend enough time and effort to reduce the majority of defects. Make it so that if they are going to occur, they’re not going to occur in the critical parts of the system. You want people to be able to engage with the most important parts of your system and have the confidence there, but depending on how important those last 10% are, you may test them less frequently. You may just accept that you’re going to rely on reports of those issues coming in and go from there.
Learning how to manage this delicate balance of skills and organisation can do wonders for your software project. Knowing when to move forward and when to evaluate efficiency are just the beginning to running a tight ship. If handled right, seeking out the best ways to eliminate wasteful processes or mindsets can actually improve the independent performance of your team members and make everyone happier with the results of their work. Adding that to saving money and time sounds like a perfect plan.
Are you looking for help on your software development project? Get in touch with us today.