Why we can’t accept work from our clients?
Answer: because all people are busy.
Why all people are busy?
Answer: There are so many projects and deadlines.
Why didn’t we plan this current work?
Answer: We planned, but it didn’t work, in addition our work has lot of defects (we call this maintenance to be nice).
Is this maintenance sort of new feature?
Answer: NO, it’s failure from our side and considerable percentage of our people effort is spent addressing them.
Why you didn’t tell me about that before
Answer: none… ** Fear **
Symptoms of Fear behavior:
- We are always busy
- People are forced to do work on expense of quality. We create our own technical debt.
- We always change priority
- We don’t dare to ask our manager to give us work because of available capacity
- Presence of heroes
- We create defects
Please add other symptoms.
The product backlog is arguably the most important artifact for Agile team.
The problem is how to ensure that the product backlog timely includes all requests with their relative prioritization apart from their source.
This takes us to the product owner role in managing the hand-offs from demand to the development team(s) using the product backlog as medium of communication.
The biggest team complaint is that there are back doors for pushing requirements. This situation leads to:
– The team takes prioritization decision.
– Rift the team from following the value stream due to uncontrolled work as it’s not included in the visual board.
– Compromise the product by making the team working at low value requests.
As shown in the diagram, the product owner is responsible to coordinate with all possible sources of requests and translate their needs into prioritized backlog items. The backlog item is a card on the visual board and can either be MMF, Defect or Service. It is important to have explicit policies for each of these three types. Adding the dimension of priority (regular, target date and urgent) can add rules to these policies.
Finally, being a gate-keeper, the product-owner can ensure:
– The integrity of the product,
– Avoid adding requests which create technical debt,
– Assume ownership on the product acceptance, and
– Be considered by the team as the ultimate authority for clarifying requirements.
The technical debt log is valuable organizational artifact that should be visible especially to senior management. Please see next table for example.
The previous log doesn’t include attribution to any person. Instead it describes objectively the business situation which caused the creation of the technical debt.
For me the technical debt log should be under biweekly management review. It’s part of the organization sanity checking for its management and quality practices. Technical debt forms the real liabilities of the organization which are not commonly addressed in their financial statement.
Technical debt log is one input for product road-map because it can create the need for future projects for architecture enhancement. This log helps to understand the business value of architecture enhancement instead of limiting the business value to new features only.
The technical debt log can be proponent to drive process improvement on where is the highest return for the buck for process change. It is interesting to see how the business situations are repeatable indicating common pattern in our business practices. This is the essence of change management driven by real data of liabilities.
– Write code without having test cases
– Unavailability of required skill to complete features to be demonstrated to client
– Check-in code without having continuous integration server
– Deliver software to clients which can only be implemented by engineers instead of client facing consultants
It’s proactive if we can visualize issues assess their impact. This impact can be immediate by clogging the flow or by inheriting more owing to our already building up technical debt.
Root cause analysis done after confronting failure is of little value. It’s after the fact and tells us what we should have done earlier. Root cause analysis is excellent for learning; however, if we lack the ability to translate this learning to practical actions, the value is little. For example, analysis of root cause of being diabetic is useful, but the cost of correction is prohibitive.
Producing client valued software which is not easy to implement is consequence of decisions we made at the early steps of our delivery cycle. The surge in the implementation cost from one client to another can lead to re-architect of the product, instead of adding enhancements to the product to address new market challenges.
Many of the above consequences could have been highlighted as we visualize the flow of value prior to delivery. It’s not enough to remove the issue to enable flow. The learning we gain from assessing the issue impact at the moment when it happens is vital for organizational learning and change management.
Visualized issues are opportunities for organizational growth through learning. We as software organizations can only grow by learning and imparting this new knowledge in our development practices and work standards. This learning is unique to every organization and it questions our DNA and work tradition. Resolving issues related to technical debt is where we shift from the current-state to the future mode of operation.