Don’t make a decision today that you can put off until tomorrow.
Many product manufacturers like to operate with minimal finished product inventory. They follow the principle of postponing the final build process until a customer order is in hand. That’s lean thinking.
This technique enables them to optimize cash flow and minimize the risk that a change in customer direction will leave them with a large quantity of finished goods that few people want. They don’t commit to the final product until the customer has committed. (At one time Dell Computer was the poster child for this approach.)
Agile software development processes can apply a similar technique. Don’t make a decision today that you can put off until tomorrow. That may be a little extreme but the idea is to postpone decisions that are expensive to implement and/or irreversible. Those commitments should be made as late as possible in a lean development process.
It’s not easy to procrastinate.
You can’t postpone every decision until the last sprint. You can’t even postpone most of the major decisions until then. Some things have to be decided early but even then, there are techniques for maximizing the effectiveness of those early decisions.
Get into the habit of asking a few probing questions prior to making irreversible decisions.
- Does this have to be decided now?
- Is there sufficient information to make this decision now?
- Will new information be available later that may affect this decision?
- Is there added cost or risk in postponing this decision?
- What are the cost and risk of making the wrong decision now?
Armed with the answers to these questions, you’ll be in a better position to make the call. Once a decision is made, turn your attention to the implementation and ask a few “what if” questions.
- What if this decision doesn’t work out as planned?
- What if the customer decides to change the software feature set?
- What if the company decides to go up-market or down-market with this software?
The idea is to get the team thinking about flexible implementations using such things as parameter files, database-driven designs, and software interfaces. Being agile refers to more than the team’s behavior. It also refers to how the software is built.
Anything about the solution that can change, probably will. Whether you’re following Kanban, Scrum or XP, introduce a little lean thinking into the process.