Work-in-progress — costly, cumbersome and confining. Product manufacturers go to great lengths to avoid work-in-progress (WIP). WIP is anything that is unfinished. This includes artifacts that help in producing a product, not just the final product itself.
Why is WIP bad?
- Costly to store and manage.
- Must be maintained and upgraded as needed.
- Inhibits the companies ability to make changes.
Now consider software development. WIP artifacts include business requirements documents, functional specifications, technical specifications, user interface designs, database models, etc. All of these waterfall software development artifacts are WIP because they are not final products in themselves. They contribute to the construction of the final software.
All these artifacts have to be stored, maintained, upgraded, revised, etc. anytime an unplanned change is made to the software. It is no surprise that waterfall teams are reluctant to accept changes. Every change presents the potential for a lot of work.
Many teams are so change-phobic that they construct elaborate change management processes and change control boards to discourage change. It does not get any more anti-agile than that!
Agile development is a better way.
Agile approaches like Scrum, XP, Kanban and, of course, lean software development, seek to minimize WIP and embrace change. Is your company opposed to change? Is it stagnant? Does it stand still?
If so, forget about agile development. WIP will not be a problem.
However, if your company embraces change; if it moves rapidly (or would like to); if it competes aggressively in its markets, then you need to be using a development approach that minimizes WIP.
Agile approaches advocate just-in-time (JIT) delivery of artifacts. For example, stories are kept small and not finalized until the team is ready to build the underlying code. All of the stories are not defined and written at the outset because it is acknowledged that some of them will change.
Likewise, other artifacts like user interface elements, software design documents, test elements, etc. are delivered JIT to minimize WIP. This keeps costs down and embraces change.
These are not novel concepts. They are tried and tested in companies around the globe.
If you don’t like Scrum, XP, Kanban, etc., fine. No approach is perfect. The question you must answer is, “What are you doing to deliver software artifacts just-in-time and how are you minimizing work-in-progress?”.
If you are not working toward those goals, you will never be agile.