- Frequent Delivery
- Osmotic Communication
- Reflective Improvement
Crystal Clear is based on the premise that the ultimate success of any software is to have a satisfied customer. This may be what is written in the specification but more often than not, it is different from the specification. When the customer embarks on a project, they themselves are not exactly clear as to what is possible by the software. As the software is developed, they get a clearer picture of the software and usually have some changes to how the software operates.
Traditional (non-agile) processes place a great deal of emphasis on having a detailed specification which is agreed upon at the beginning and signed off by both parties. When the software is finally delivered, the customer often finds that the software doesn't do what they had in mind, while the developers point to the spec and show how everything that was agreed upon has been implemented. Making changes at this point could cause massive redesigns, but at the same time the customer is not happy with the product. Neither side is willing to move, with the result that the software is ultimately a failure.
Crystal Clear emphasises frequent delivery instead. Deliver working software to the customer every few weeks. This has two major advantages. One, the customer has some working software with periodic updates. This keeps up the customer's confidence high that progress is happening. It also gives the customer visibility into the project and enables them to keep track of the progress. Secondly, it gives them the opportunity to use the software and come back with feedback. This feedback is easier to incorporate because the software is still in development.
Another advantage of frequent delivery is that it also gives confidence to the developers that the project is moving forward. It builds morale when you see new features in the hands of the customer every few weeks. There is nothing as draining to developer morale as long projects with no end in sight.
Delivery cycles in Crystal Clear are around 3 weeks to a couple of months in duration. During a delivery cycle, you pick the features, implement, integrate and test them and then pass it on to the customer. The actual duration of the delivery cycle depends upon the project. The delivery cycle should give enough time to implement, integrate and test a few features. Apart from that, shorter delivery cycles mean quicker feedback from the customer.
Thats it for frequent delivery. I'll cover osmotic communication and reflective improvement next.
This post is a part of the selected archive.