Simplicity of code and process are aesthetically pleasing. Yet there’s a more important reason why agility helps you create great software: it improves your ability to recognize and take advantage of new opportunities.
If you could predict to the hour how long your project would take, know what risks would and wouldn’t happen, and completely eliminate all surprises, you wouldn’t need agility—you would succeed with any development method.
However, what you don’t know is exciting. A new crisis or happy discovery next week could completely change the rules of the game. You may discover a brilliant new technique that simplifies your code, or your customer may develop a new business practice that saves time and money.
Want to deliver real value? Take advantage of what you’ve learned and change your direction appropriately. Adapting your point of view to welcome changing requirements gives you great opportunities. Delivering value to your customer is your most important job. Aggressively pursuing feedback from your customer, from real users, from other team members, and from your code itself as early and as often as possible allows you to continue to learn and improve your understanding of the project. It also reveals new opportunities as they appear.
Agility requires you to work in small steps, not giant leaps. A small initial investment of time and resources, properly applied, begins producing quantifiable value immediately. As well, committing to small amounts of change makes change itself more possible. This is most evident when customer requirements outline their needs at a very high level, through stories that promise further clarification during development.
Aggressively seeking feedback and working in small steps allows you to defer your investment of resources until the last responsible moment. You can start to see the value from a piece of work as you need it, rather than hoping to benefit from it someday in the future.
XP exploits agility by removing the time between taking an action and observing its results, which improves your ability to learn from this feedback. This is especially apparent when the whole team sits together. Developing features closely with the on-site customer allows you to identify potential misunderstandings and provides nearly instant responses to questions. Including real customers in the process with frequent deliveries of the actual software demonstrates its current value to them.
XP allows changes in focus through short work cycles. Using simultaneous phases enables you to put a lesson into practice almost immediately, without having to wait for the next requirements gathering or testing or development phase to roll back around in the schedule. The short work unit of iterations and frequent demos and releases create a reliable rhythm to make measured process adjustments. Slack provides spare time to make small but necessary changes within an iteration without having to make difficult choices about cutting essential activities.
I worked for a small startup whose major product was an inventory management system targeted at a specific retail industry. We had the top retailers and manufacturers lined up to buy our project. We were months away from delivery when our biggest customer ran into a problem: the license for their existing point-of-sale system suddenly expired. The software included a call-home system that checked with the vendor before starting.
Our plans included developing our own POS system, but that was at least several months away. Our current system managed inventory, but we hadn’t done specific research on supporting various terminal types, credit card scanners, and receipt printers.
This was our largest customer, and without its business, we’d never succeed.
After discussing our options and the project’s requirements with the customer, we decided that we could build just enough of the POS system within six weeks that they could switch to our software and avoid a $30,000 payment to the other vendor.
We were very fortunate that our existing customers needed very little work from us in that period. We shifted two-thirds of our development team to the POS project. Though we started from an open source project we’d found earlier, we ended up customizing it heavily.
After two weeks of development, we delivered the first iteration on a new machine we had built for the customer to test. We delivered weekly after that. Though it was hard work, we gradually added new features based on the way our customer did business. Finally, the only remaining task was to change a few lines in the GUI configuration to match the customer’s store colors. We saved our customer plenty of money, and we saved our account.