Search This Blog


Monday, March 17, 2008

The Premises of Agile Programming

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:
  1. No fix price contract
  2. The willingness and the ability to prioritize.
  3. Done MUST mean Done
  4. Full suits of unit tests
  5. 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!


Goldfish said...

I like the article. It resonates with me. I just wish I could get the customer to agree to no fixed-price contracts. That part is out of my control. So, we have to settle for pseudo-agile practices. For me, step #1 is the unit testing. TDD is the way to go!

Soon Hui said...

Thanks goldfish, I am glad that you like TDD, just like I do :)

Dantelope said...

There is nothing in agile practices that prevent fixed price contracts. On the contrary, fixed price is a fabulous way to go.

What you generally cannot have is a fixed price and fixed scope.

Do not confuse fixed price with fixed scope. Essentially, I'll give you a fixed price and do as much as you can prioritize and I have time for. If time runs out, I'll have done your high priority items and you'll be fairly happy albeit not done.

A good consulting company should be able to come up with a reasonable time frame to complete a generally specified work order, even if the process used is agile. As the details unfold, however, the scope can change (usually it decreases by the product owner's own reprioritization of unimportant things towards the bottom of the backlog).

I am currently doing a not-to-exceed price project in an agile format, so the proof is in the pudding.

Soon Hui said...

dantelope, thanks for complimenting my point.

But I found that generally, fixed price without a fixed scope is not possible if you have to tender a project. During the tendering stage you need to come up with a cost and scope estimation of what you are going to do. In this case, I doubt whether Agile Programming practice can help or not.

Dantelope said...

Think of it this way... the fixed price buys you a fixed amount of development. What is produced from that development is entirely up to you based on your prioritization and the productivity of the team.

It's a harder sell than fixed price / fixed scope because, as you said, people are accustomed to the waterfall, but there is nothing inherently preventing it.

Philk said...

so if you dont have an extremely talented developer you cant be agile ? I thought agile was about high-performing TEAMS that can outperform a solo 'rock star' programmer ?

Soon Hui said...


What I said was without extremely talented programmers, agile methodologies are likely to fail than waterfall model, all other things being equal.

Agile Programming puts so much control and responsibility into the hands of the developers; agile programming is so developer centric that the quality of the developers is the most important factor in determining the fate of the software projects. True, extreme programming encourages collective code ownership and things like that that spread the risk of a single developer being ill, but to imagine that agile programming can make a bunch of average developers do what a single rock star developer can do is just not possible. If anything, agile programming will only make a team of average developers to fail faster because there is no one above them to guide them.

PascalAschwanden said...

Agile programming has its place in the programming world. People need to remember why their using it instead of blindly adhering to policies no one really understands.
Programming Language Questions & Review