Puzzled manager (Fear)

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:

  1. We are always busy
  2. People are forced to do work on expense of quality. We create our own technical debt.
  3. We always change priority
  4. We don’t dare to ask our manager to give us work because of available capacity
  5. Distrust
  6. Presence of heroes
  7. We create defects

Please add other symptoms.

Gate Keeper

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.

 

Technical debt log

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.

Situation

Decision

Impact

Cost implication

Total cost-to-date

Est. cost to do it right first time

Debt removal plan

We had to meet the deadline of 11/5/2009 become the client wanted to release the service before the competition.

De-scoped the customization functionality for power users configuration.

For every product roll-out we need to customize the functionality ourselves. Moreover, we receive “x” service requests from each client in average monthly to do some feature configuration.

The ticketing system shows that we spend in average 20 hours per month per existing client for configuratbility. Also, the level of configuring the features for new clients is 120 hours.

5400 hours at rate of $80/hr = $432,000

200 hrs = $16,000 with 3 weeks extension

NA. This due to having various interfaces and dependencies which we still need to assess the risks. There are other costs related to making changes also in other related products.

Flow clogging- is it Issue or Opportunity?

For me, Issue is the inability to timely complete work according to the criteria of DONE. For example:

– 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.