In Part 1, I talked about eliminating waste in a Scrum environment and the first two types of waste in software development. Here I talk about the remaining types of wastes, giving some examples and ideas to help you eliminate or, even better, avoid waste altogether. I’ll continue from ‘Relearning’, the third waste type.
Most projects have many systems and processes that the development team work on. The team should be aware of how to work on these systems and follow the proper processes, as well as learning the technologies used within the project.
Imagine the amount of time and effort that would be wasted if development team members had to learn the same processes and technologies twice! This usually happens when you provide learning to team members when they’re not using that knowledge. Then, when the time comes and they’re actually required to use it, they usually have to go through Relearning to regain that knowledge and get the benefit of it. This means that there was no value added from learning the first time!
To overcome such issues, the team should have a proper process for knowledge sharing. This could simply be a knowledge-sharing location that the team agrees to maintain. Information must be transparent, accessible, easy to understand and properly organised. You should reach a stage when team members are aware of the information they require at any given time and know where to find it and can easily pick it up.
You can always approach your team mates or knowledge experts within your project environment for support. This way, you’ll save the project time and avoid relearning.
Another form of relearning is the time spent trying to decode! Sometimes developers suffer from poorly written code or too complex code. When the project maintains a well-written and documented code, it saves the team heaps of time and makes it easier for any developer to fit in and make further changes.
Many factors can cause ‘relearning’ waste to occur, so keep an eye open for any signs of repeated learning happening within the project at all the phases. Track it down and try to avoid it from happening again. Ensure the team works on regularly capturing and maintaining knowledge.
With the high turnover of people in the IT market, the team will need to spare some time for handoffs/handovers. The more complex the project is, the more time and effort is required on those handovers. If this isn’t done successfully, you might end up with poorly managed handoffs that leave the new team member stuck with a lot of work that she/he has no idea of how to handle. This could result in even more waste of time spent trying to find the proper person to give support or pick up the undone work!
So work that is being passed among different team members is a ‘Handoff’. Avoiding handoffs between the same team members is hard to do, but can be manageable. Think about how much time you usually need for a proper handoff, and always be prepared. Get the team to document as they go. It doesn’t have to be comprehensive documentation but just enough to be understood. Think about keeping a simple live document where different team members can access and add things they know about, e.g.technologies they’re using, systems they’re working on and processes they follow. This can save the project heaps of time when there’s need for a handoff.
The most instructive documents are usually created during handoffs or implementation of new technology/processes. Just make sure those documents are live and being maintained by the team. Then you can experience how much time and effort you have saved on future handoffs.
And remember that handoffs between your team and external teams can get a bit tricky. Try to make sure the work you’re handing over is transparent and easily understandable by the other teams.
We usually lose focus when we start working on a certain task but then get distracted by having to do another. Most of us face this issue on daily basis! As well as losing focus on what you were doing, you will then need to start thinking about the new task in hand and take some more time to regain focus on the task you were already working on. This would create some waste in your time and effort. But how do we overcome that?
Try to always focus on the higher priority tasks/stories on the board and don't be afraid to say no. You can respectfully let the team know that you’re focused on the task in hand and, with their agreement, pick up the other task later. You will then be more focused and more productive on the new task rather than having to work on the task with half a mind.
Keep an eye open too on the tasks that can emerge from external teams. Remember that you can only work on tasks that are already agreed on between your development team and the product owner. If any new tasks are required to be done by external teams, they still have to go through the product owner who can then prioritise them in the backlog and can be picked up later.
So, do your best as a team to be self-organising. Help each other to complete the tasks in hand and try to minimise the time spent on switching back and forth between different tasks.
Many factors can cause delays, including unnecessary bureaucracy, slow or ineffective communication, delays in processes etc. There are many methods that can be applied to capture where the delays are occurring and how the team can work on overcoming them.
A Retrospective is always a good place for the team to highlight any delays that occurred during a sprint and work on a way to improve them. A Retrospective can always be applied for other processes, not just the sprint. In my current project, our Scrum Master, Peti Morgan, has carried out a Release Retrospective where all the teams involved in the release process joined and added their input. This allowed us to achieve a tangible improvement to the process.
Anything that would cause quality issues for the project is considered a defect and accordingly would generate waste. Think of the amount of time and effort spent on finding the defect, fixing it, retesting it and then regression testing. And double that time if the fix did not work or it created another defect instead!
Having an automated regression suite in place can always help the team get faster feedback and provide evidence of reliable quality. In addition, using the following Testing Pyramid and having automated tests in place at every possible level would result in higher quality software.
Unclear or changing requirements can also be a major cause of defects. Take your time to understand the stories and try to keep them simple. You can always let the product owner have a look at the developed piece of functionality before you even consider it for testing just to confirm you’re on the right track.
There are many techniques that can help the team avoid defects – Acceptance-driven testing, refactoring, pair programming and others.
Be focused. Make sure the team is dedicated to a common goal and that they’re committed to achieving it. Also, remember to be flexible and comfortable with jumping into other roles. Having a sense of ownership and sharing a common purpose will allow the team to help each other, whenever possible, to achieve that goal.
At Sprint Planning, be careful not to underestimate stories and try to fight that urge to take on more stories than you could deliver. It is the whole team’s responsibility to deliver what was committed to. Having a visible burndown chart to track your daily progress could be of a huge help. You could easily notice the risk of falling behind and anyone could raise a flag at any point of time and ask for support to get back on track.
Spending time and effort on identifying and eliminating waste generated in a Scrum environment can help improve the quality of the project and save time. Always remember to analyse your current situation, identify any waste, weigh your risks and continuously improve by eliminating the waste identified.