When you’re working on a challenging software project, you want to move forward as fast and as efficiently as possible. Coding is a challenging process that sometimes cannot be rushed. It is vital to a successful project to be organised at all levels. It is just as important not to disturb processes that run efficiently. Watch this video to learn about the nature of excess in software creation, and gain a few tips to help you run a smooth operation.
Video Transcript:
Addressing waste in software development
A quick recap
Waste in software development is any effort that occurs in a project that doesn’t result in value for the customer. There are seven types of waste that we’ve talked through. I’d urge you to think through your own internal processes; whether it is for software development or just the day to day running of things.
Look at the number of people who might be engaged in doing a single task when it comes to hand offs.
Look at the number of times you’re tapping on the shoulder of someone who is trying to do an in depth task and saying, can you change what you’re doing and do another task for me? That one has a huge impact on that person’s output.
How does waste in software development apply to our projects?
Every project has waste. Every one of my projects has waste. The first step is just accepting that this is the case. Just think of it as, it’s a reality – I want to learn about the waste that is in my project.
Examine your system and identify where waste is. Where you find it, do that analysis, determine whether it’s worth changing things now. If not, start a waste log. Just note the places that you’ve seen waste and over time you may have an epiphany. You may have that moment where you realise how you can change one thing that will address multiple parts of the system, multiple bits of software development waste that are occurring in different ways. If the cost benefit analysis says it’s worthwhile changing, then amend the system to account for that waste.
Waste evasion techniques
I’ve got some options in here, looking at a few of the types of waste we’ve been talking about and ways that you can address them.
Task switching
So task switching is the first one. This is a pet peeve of mine, so I’ve got a heap of different options when it comes to this one.
- Technique #1. Raise the cost. If the interruptions come from external clients, consider increasing the price to the client of interrupting your process. Everyone always think that what they’re dealing with at that time is the most important thing in the world, literally the most important thing. Nothing you had on is nearly as important as this thing. But if you suddenly doubled the cost to address the issue, all of a sudden they’re doing a bit more internal accounting and thinking, maybe that can wait until tomorrow when the cost goes back to the old cost. It really makes them examine the criticality of things.
- Technique #2. Have a support team and a feature team with one team shielding the other. You have a dedicated person, we used to have this with Noble Samurai. We would work on a cycle where we would have three devs as part of the feature team and then we had a dev who was considered the shield for the week. We actually had a little plastic shield that went on their desk. Their job was to work with the support team dealing with client enquiries. They were dealing with the day to day things and answering the in-depth technical questions, potentially deploying small fixes, but their job was to make it so the other guys could sit with their headphones on and get on with the heavy lifting.
- Technique #3. Work in chunks. If you can break your working day into chunks of three hours or so, you generally get two of those in a working day, and you need the internal discipline not to break from those chunks. What you say is, a critical issue at its worst may take three hours before you’re starting to address it. If you find out five minutes into the chunk and you wait until the end of the chunk before you start addressing it, only three hours have gone by. There are relatively few issues that are that important. Working in chunks means that people get enough time to properly get into their rhythm. Particularly for developers, three hours is a good amount of time to properly engage with a problem and start to work on it. It gives you the best of both worlds. It gives you flexibility a few times a day whilst still giving them a chance to dive into things.
Relearning the process
- Technique #1. Batching your work into features and fixes that are alike. Build yourself a backlog of issues or some sort of register where you collect all of the ideas and changes you want to make and deliberately impose upon yourself a cycle time. Say, every month you’re going to sit down and look at everything everyone has logged. This is going to obviously except the critical emergencies. You build yourself this backlog. You collect everything together and then you start to batch things up so people are working on one area of the system once rather than having to continuously revisit it.
- Technique #2. Document where required and where useful. Some areas of the system just don’t require documentation, some do. If you find an area of the system that you do have to keep returning to and you have to make multiple fixes to it, that is an area of the system where more documentation is helpful. Let the needs of your system, and this works for general business processes, whenever you have a system that is complex and changing relatively frequently, keep that part documented. But all the day to day work that people just get, don’t worry about it. Pick and choose your times to do documentation.
Defects
- Technique #1. Increase the rigor of the rules in your system. If your workflow has one testing phase currently: the feature gets developed and then it is tested by a tester and then it goes live. And if you find you’re still getting a high error rate, consider adding a second test in there, a different type of test. So for instance, the issue that is occurring might be one where a front end tester isn’t going to pick it: e.g. everything appears to submit correctly on your form, but some of your form entries are just being dropped quietly and nothing is ever happening for them.
- Technique #2. Introduce new work phases. You might want to introduce a code review step, a different type of testing, that means another developer is looking over the work. With a number of our projects we’ve got phases of internal testing and we’ve got phases of external testing. So increase the rigor of your system to account for defects.
- Technique #3. Improve communication between phases and between workers. When you’re working with complex features that have to pass between multiple people doing different tasks, the more separated they are and the fewer opportunities they have to communicate, the more error prone things become. If you only allow people a single chance to talk, that requires them to have everything covered in that one conversation. They have to have thought through all the edge cases. They have to have passed on every bit of information to the next phase. The more opportunity people have to ask questions and to communicate, the more in-built flexibility you have in your system. Where people can talk, the lower the chances of defects getting through to a live environment are. They’re still going to exist, but you’re going to address them before they get into a situation where they’re threatening customers.
So, you can see how important it is to design the most effective way for your team to work together. Interrupting the coding process to make sure that other systems are moving forward can be a critical error to progress. Just as much, though, allowing work to continue without a system in place for testing and re-testing can lead to wasted time and money. Finding the perfect balance by setting goals and breaking the work-time into the ideal length and patterns is the best solution.
If you need help organising your software creation process, we’d love to hear from you. Get in touch with us today.