This post describes my own view on waste in software development. I recommend reading Mary Poppendieck’s book here. I was inspired by discussion with a bit frustrated product manager who mentioned that unless the organization understands how waste harms the bottom line, chaos would continue. I had communicated the term waste in earlier training but as he talked I found that he has a wisdom that wasn’t part of my training. I felt he is like a war veteran who talks from realities and try to relate to theories. However, in my training I was theory oriented while providing applications. What energized me is his statement “should work on waste if we want to improve the bottom line”.
The set-up is product development company with diversified portfolio around multiple engineering teams. The problelms, in my view, are described as follows.
Aspect 1: Composite feature
Composite feature require sheer coordination among various engineering teams and other supporting teams. Teams tend to work in isolation to deliver against the estimates of their release plan. The assembly process of the composite feature from the deliverables of teams is high risky. It assumes things will work, while the truth they seldom do. This assembly process creates a project by itself with adverse implication on schedule, quality, requirement, and most importantly people. Whatever we do to get the teams together to resolve dependencies during the time of delivery didn’t work.
Aspect 2: Hidden factory
The organization employs ticketing system; however, there is inaccuracy in semantics. A defect can be classified as new feature. A requirement defect can be classified as enhancement and so forth. The reality is that we are in continuous maintenance mode to pay for the technical debt. We don’t to acknowledge that we create our own technical debt.
Aspect 3: Shared resources
We are obsessed by utilizing our intelligent developers to the limit. We keep re-assigning various developers to different teams which require same technical skills. In various retrospective meetings, developers were vocal on their inability to perfect their work before deployment and that they are always in-demand by other teams. Quality is affected tremendously and most importantly motivation level becomes low. This in line with Dan Pink’s conclusions that passion for mastering skill is a key motivation driver.
Aspect 4: Invalidity of product road-map
In such high pace industry, the company is catching with changes in product trends which updates very quickly its product road-map. The product managers can’t really plan the features because engineering teams end up being asked to complete unexpected features. The product manager becomes more as a relay for the requirements to the team and doesn’t add enough value in terms of business analysis. She became non-capable to pair with architects to figure a solution for realizing the feature that meets reliability, quality, portability, performance, and other requirements.
Aspect 5: Deploying while developing
The deployment teams should be able to deploy the product with minimum dependency on engineering teams. This is the value add deployment teams are supposed to add to the value stream of product delivery. However, the dependency on the pengineering teams is growing. This causes more distraction to engineering teams; increase the work of hidden factory, less ownership from deployment teams, delays among few.
Aspect 6: Failing to create coherent design
We operate based on a partial set of requirements to develop certain sub-features for learning. In incremental design, the feedback we receive improves our understanding to strengthen the design in iterative delivery cycle. We fail to implement this philosophy which makes us not able to start development till the requirement is complete which rarely happens. This create delays and static designs.