Agile Programming promises a lot of things. With its emphasis on face-to-face interactions over documentations, incremental development over Big Upfront Specification, self-organizing teams over top-down heavy-factory management, Agile Programming is like the Garden of Eden in the eyes of the developers who are smart and independent and abhor all the negative things that are associated with the waterfall process.
True enough, Agile Programming is very useful in developing high quality software in a short time. Normally when you pick up any books preaching agility you will see them enumerating all sorts of benefits associated with it. OK, I don't deny that Agile Programming is very promising. But in all the literature regarding Agile Development ( and all its variants such as XP, SCRUM), the premises of Agile Programming is conspicuously absent.
Nothing is easy, including getting the most of out Agile Practices. In fact Agile Programming requires strict disciplines and prerequisites. You need to have them if you want your projects successful. Here are them, in no particular order:
- No fix price contract
- The willingness and the ability to prioritize.
- Done MUST mean Done
- Full suits of unit tests
- Extremely talented, motivated staffs
No fix price contract
Agile Programming does not believe in Big Upfront Design. There is no point in drawing out detailed design at the start of a project when it is the riskiest and when most is uncertain. No only that, at the start of a project the customers may not even know what they want, create a detail spec and bid on it is simply nonsensical.
Doing fix price contract project requires you to come up with all the requirements and the estimations at the very time when you are least capable of providing both. This is unrealistic and do no good to both of you and your clients, as the specs and the estimations will continue to evolve throughout the project. The traditional waterfall-model-way of handling this is to discourage request changes by penalizing late request changes or simply disallow them; Agile Programming, on the other hand, recognizes and embraces changes in order to meet customer satisfactions, not to meet the specs.
Fix price contract is a vestige of waterfall model. It is not applicable to Agile Programming.
The willingness and the ability to prioritize
At the start of every iteration, features must be prioritized. Every iteration is a new start, so the Program Manager and the developers must seat down together to discuss what is important and what is not.
This is not easy in practice.
Developers like coding. Ask them to seat back and prioritize features runs contrary to their habits. Once they start coding, there is a momentum and it is best left undisturbed. Every meeting with Program Manager is annoying, moreover, it disrupts the rhythm, brings down the productivity, brings back the feeling of bureaucracies... and so on. In sum, priority meeting, or any meeting sucks, as far as the developers are concerned.
A good Program Manager should make his developers like to attend such a meeting. Failing to do so will see your developers working on the most fun items, not the most important items.
Done MUST mean Done
Software development is notoriously hard to estimate. Developers have the habit of underestimating the coding difficulties and overestimating their capabilities. A feature that is estimated to take 1 month to finish can take up to 3 months to finish in practice.
Even so, there are bugs in the features that will require another 2 months to fix. So in total, that feature requires 5 months to complete.
But in order for any planning to work, the schedule and projections provided must be fairly accurate. If a done does not mean done, then the schedule is doomed anyway, regardless of whether Agile Programming is practiced or not.
Full suits of Unit Tests
Agile Programming relies on constant refactoring in order to meet changing requirements. But without safety nets, every change incurs extra risk. Without unit tests, there is literally no hope in being agile and maintain high quality code at the same time.
This is, in my humble opinion, the second most important ingredient of Agile Programming. You can't say that you are Agile if you don't have unit testing. I don't care how many SCRUM meetings you have, I don't care how often your specs get change, I don't care how responsive you are to your customers. If you don't have unit tests, you are not practicing Agile Programming.
I know this sounds dictatorial. But please honestly ask yourself this question: If you don't have unit tests, how can you make sure that every change you introduce will not cause regression bugs? If you don't have unit tests, you will either be not adapting to the changing needs, for fear of breaking the existing builds, which means that you are not agile at all, or you are being agile... in a bad way.
Extremely talented, motivated staffs
This is the single most important ingredient of Agile Programming. Not just Agile Programming, but every worthwhile endeavor. But Agile Programming is such a developer-centric process that the quality of the developers matters a lot. You rely on the developers to provide you with an accurate estimations of the features, you rely on the developers to do the coding, you rely on the developers to refactor their code when the need arises, you trust them to do their own unit tests. In short, you count on them exclusively to do their best.
A good programmer can be ten times as productive than a bad one. If you have bad developers, or you have the nasty habits of demoralizing your developers, then Agile Programming isn't for you. As a Program Manager, your task is not to manage the developers, but to lead them, to inspire them, much like how soccer coach inspires his team to glory. Creativity cannot be managed; it can only be inspired.
Keeping the developers happy and stayed motivated is hard, just like keeping the already well-fed soccer superstars happy and motivated is hard. But this is why not every one can be Jose Mourinho, right?
So here it is, five important premises of Agile Programming. Don't forget to add them to your check list should you decided to go agile!