I recently watched The Haunting of Bly Manor on Netflix to satisfy an itch for a ghost story. It’s a story of restless spirits, driven by unsatisfied love, betrayal, and abandonment. All the characters in the story shared the same locale with specific roles to maintain a working household. But they shared a common fate under a spell of captivity because a key yearning wasn’t satisfied. I know this is creepy and off-center, but what would it look like if our processes that produce waste in software development were equated to restless ghosts? We too have a yearning to eliminate wastes because they can be scary and haunting. So here’s a spooky tale as you head into your Halloween weekend.
Transfer of Work/Unnecessary Movement
We gain efficiencies in our processes when we transfer work between groups as few times as possible. The number of transfers is minimized when the hand-off has enough information to be clearly understood and is actionable. It’s worth the effort to make the hand-off as complete as possible to get the desired work output. But in the agile manifesto it states “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage” and “ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” So as practitioners, we have to find a balance between delivering software quickly and not creating waste. Be careful or you might end up with a scary version of what you wanted to build.
Another key waste is doing work that is never used which creates unnecessary inventory. It reduces the overall contribution of the team to the financial goals of the organization. The agile manifesto promotes “Simplicity–the art of maximizing the amount of work not done–is essential.” There may be a need for prototypes, concepts, and the like. But can we structure these in such a way as to make them reusable or to serve a specific purpose. Unused inventory is like creepy dolls that have no one to play with them.
Another behavior that creates waste is not recognizing knowledge that may already exist for how to solve a problem. Software developers are creators and have to determine when it’s beneficial to discard other work versus reusing. The agile manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams.” This can be a hard concept for some teams where the default answer is to build everything new. As with other forms of waste, there is a balancing act between remaining agile and reducing waste. Sometimes reinvention is necessary to make the project, other times we just need to reuse what was already there for protection.
Spooky tales aside, reducing waste in software development is necessary for any team who wants to continuously improve and deliver more value to the customer. If you have experience reducing waste with your team, let me know. I’d love to hear about your success!
Onward and upward!