In recent weeks, I have been asking myself this very simple question: What does it mean to be Agile? This is an important question that each team/organization has to answer before embracing Agile. It is also something that every Agile practitioner should keep in mind when dealing with day-to-day situations.
In my opinion, Agile is about:
– expecting and embracing change,
– embracing and encouraging customer involvement so as to increase visibility and reduce likelyhood of delivering a product of little value to the customer,
– being flexible where it makes sense but firm where it does not (e.g. the quality of the code base).
But that’s not all there is to it. Agile is a commitment. It’s a commitment to quality, to delivering value to the customers every week, and to providing what the customer needs.
The latter might seem tough…but it isn’t, granted that both of you are willing to have a dialogue and come up with the features that are of absolute necessity together, i.e. coming up with the Minimal Marketable Feature Set (MMF).
Focusing on what is necessary will encourage you to break down big problems into smaller ones, thus helping you figure out what would be in scope for a particular release, and what can wait the next one or can be iterated over. Doing this helps ensure you always deliver something that brings value to the customer. In theory, if you have weekly iterations, you should be able to release working software at the end of each iteration.
A side benefit of scoping things out is that quite often the customer may decide that what was left out of scope are features they don’t actually need. Had you not established a scope, had you proceeded with traditional waterfall methodlogies and planned/implemented everything, you would have wasted time implementing features that would have not brought value to the customer. There is no way to predict the future.
Because change is inevitable, one must be willing to change course when necessary. It is easy not to want to change. If you have spent a lot of time doing analysis and writing tons of documents, it would be disheartening to see all of your work go to waste. That’s why documentation should be kept at a minimun, and pre-analysis of things to come a year or so from now is a waste of time. As such, it is best to focus on the near-term and not look too far ahead. Besides, by doing the analysis when you get closer to implementing the features, you will always have the most up-to-date data.
Discussions with your customers will have what some may consider a “negative” consequence: visibility. By keeping the customer involved, there is no way to hide what’s going wrong with the project. But that is not necessarily a bad thing, as it will help set expectations and keeps you honest.
In a few words, Agile is about embracing change and being committed to delivering quality software that will bring value to the customer, while keeping him/her involved throughout the process.