Waste in Software Development and Maintenance – Part 2: Maintenance & Support

This is the second and final part of the “Waste in Software Development and Maintenance. In this post, I will focus on various wastes in software maintenance & support.

Here are the few of the wastes in software development:

1. Relearning
2. Partially Done Work
3. Handoff
4. Task switching
5. Delay/Waiting
6. Defects
7. Red-tape
8. Ineffective Communication
9. Unnecessary Complex Solution
10. Manual Execution of Repetitive Work
11. Multiple Stakeholders
12. Ineffective Monitoring & Lack of Unified Dashboard
13. The Manual Pull of Logs/Traces

1. Relearning: Here I want to run through at least two scenarios – Waterfall setup (distinct Dev and Ops teams) and Agile/DevOps setup (Dev team transforms into Ops team).

a.      Waterfall setup: Dev has completed the development and the system is in production. It is now Ops' responsibility to learn intricacies of the system. If the Dev team was kind enough, they might have documentation which is certainly not able to keep pace with the system's development speed. Dev team might organize a couple of knowledge share (sic!) sessions for the Ops team. Only God knows how much knowledge is gained by the Ops team in these sessions. For all practical purposes, the Ops team needs to invest a great amount of time and resources to learn about the system. What’s a waste!

b.      Agile/DevOps setup: during the frenzy of development, there were a whole lot of developers; Ops team was busy with existing systems which are already in the production. Now the new system is in the production, development is slowed down; the Dev team is ramping down. Even with the best intentions, only partial knowledge is retained by the Ops team

To tackle this type of waste, engage the Ops team with Dev teams early. Once the system is the production, embed Dev team members in the Ops team. If possible retain some of the dev team members in the ops team.

Wastes due to Partially Done Work, Handoff, Task Switching, Delay/Waiting, Defects, Red-tape, Ineffective Communication, Unnecessary Complex Solution, and Manual Execution of Repetitive Tasks during Maintenance & Support are similar to the Development phase.

11. Multiple Stakeholders: Once the system is in production, multiple stakeholders use the system and each has slightly different expectations from the system. This leads to difficulty in prioritization of work, and backlog refinement. In additional political weight of stakeholders drives the system toward higher entropy. This waste is difficult to handle due to its very nature. To tackle this type of waste, ensure that the system has a super owner. 
12. Ineffective Monitoring and Lack of Unified Dashboard: All systems require monitoring from various perspectives (e.g. performance, security, usage pattern, etc.). The insufficient infrastructure of monitoring and lack of inbuilt hooks in the systems to monitor lead to a great amount of waste. To tackle this type of waste development team must have a designed system for serviceability (remember DFX) and PRD must have sufficient monitoring capability and a unified dashboard. A unified dashboard will ensure that Ops teams don’t waste time and resources to shuffle around various monitoring tools. 
13. Manual Pull of Logs/Traces: Pulling out the logs and trace in case of any incident is the normal course of action for any Ops team. If this task is not automated, it requires a significant amount of resources and skill. To reduce this type of cost, automate the pull of logs/trace. Also, automate the routine analysis of logs and trace, so the Ops team can focus on deeper issues in case of an incident.

 In this two-part series on the waste in software development and maintenance, I have listed various wastes and ways to reduce them. Let me know if I have missed anything.