How much Rework you have to do?

I have been closely monitoring and also involved in the current project that we have being working on. When I say closely I really mean closely. In the last few Iterations I have being harassed by the fact called rework in the development that we begin on August 17th and 6 months from then.. I see that we have spent a considerable amount of work trying to avoid rework.. yet rework is inevitable.

We as a Team recently decided to run a check on the reasons for rework, this was due to the fact that the Team has being talking about refactoring within a month of development of the item. As a manager any type of rework is a time waste. When people moved to the lean principles the core objective was to eliminate waste (in other words rework).

We decided to find the root cause of rework... and here is what I found... maybe interesting if you have a Team doing a considerable amount of development....some of these elements if taken care can really really help you eliminate some waste... a lesson for future a learning from past....

1. Understanding

50% of the rework is caused due to the fact that the developer does not understand what he has to do and he ends up jumping into the feature development. A big job here is to involve the developer in the upfront understanding of the feature and system. Not only it is associated with the developer but analysts also tend to write use cases without fully understanding a feature... result is rework after some amount of development is done.

A timely feedback and understanding of the features can help a developer build a right feature with minimum amount of rework.

2. Test Driven Approach

How many of your developers after completing the features run a test script written by the QA , Analysts? It is important that the developer approves every Acceptance Test , every negative test before he calls in the feature as done from development. A test driven approach is not just for feature but also for the code... A peer review can ensure the facts covered or uncovered by the piece of code written.

3. Break up and Build up of Tasks

4 out of 10 developers break up tasks out of a feature... I haven't seen any building a task out of features... a micro view is what a developer build out of a feature they work on... how beneficial it will be if you build a macro view of combination of features? Well the Architect and Managers have architectural views at higher level.. but if you understand the fact that what other features may need you may avoid duplicate work or rework.

4. Refactoring Yes , Reorganizing NO

Give time to your developers when they write code... not to let them re-organize what they deliberately left out or to cover what they did not finish.. but to reform the code in a better way. If your developer comes to you the next day after he finished a feature asking for a refactoring time, he has messed it up.. and the refactoring time is not the quality time.. its the development time.. he is running short on estimates.

Clearly define refactoring time.. and that is not development or bug fixing time.

5. workarounds vs Driveways

Developers always tend to bring workarounds as permanent solutions... they think from a granular perspective... train your teams to answer a few WHY... when they ask or suggest a solution?

Questions like :

Why this has to be done?

Why can it be not done later?

Why it was not done earlier?

Why this time?

Agile Teams eliminate the rework element to a bigger extend.. Agile Test Driven Teams eliminate it a very large extent. Agile behavioral development Teams can eliminate the larger chunk too... but yet Agile Teams too have to put rework. The project plans have to consider this fact and build an expectation accordingly. As a manager it is our job to ensure that we consider a few of the above elements and avoid some rework.. after all it is boring, time consuming and unpleasantly wasted.