The Agile Alliance Manifesto

These are some truly mind blowing, eye opening rules (to a newbie anyway)… here are some extracts from the book (Sorry about the mass copying & pasting, I just had to include each and every word of it… they are simply well meant.)

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to changes over following a plan

Here are some points from the book I think are really helpful in understanding these rules…

1. Individuals and Interactions over Processes and Tools.

“People are the most important ingredient of success. Principles, patterns and practices are important, but it’s the people who make them work. We cannot manage teams of developers as if they were systems made up of components driven by a process, plug-replaceable programming units.

A strong player is not necessarily an ace programmer. A strong player may be an average programmer but someone who works well with others. Working well with others, communicating and interacting is more important than raw programming talent.

Tools can be overemphasized. An overabundance of big, unwieldy tools is just as bad as a lack of tools. Don’t assume that you’ve outgrowns a tool until you’ve tried it and found that you can’t use it. Don’t assume that bigger and better tools will automatically help you do better. Often, they hinder more than they help.

Building the team is more important that building the environment.”

2. Working software over comprehensive documentation.

“Software without documentation is a disaster, however, too much documentation is worse than too little. Huge software documentations take a long time to produce and even more time to keep in sync with the code. If they are not kept in sync, they become a significant source of misdirection.

It’s always a good idea to write and maintain a short rationale and structure document that discuss the overall design rationale and only the highest-level structures in the system.

If all we have is a short rationale and structure document, how do we train new team members about the system? The two documents that are the best at transferring information to new team members are the code and the team. It’s difficult to extract rationale and intent from the code, but it’s the only unambiguous source of information. The team holds ever-changing road-map of the system in its members’ heads. The fastest and most efficient way to put that road map down on paper and transfer it to others is through human-to-human interaction.

Martin’s First Law of Documentation

Produce no document unless its need is immediate and significant.”

3. Customers collaboration over contract negotiation.

“A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed. In most cases, the terms it specifies become meaningless long before the project is complete, sometimes even long before the contract is signed. The best contracts are those that governs the way the development team and the customer will work together.”

Software cannot be ordered like a commodity. You cannot write a description of the software you want and then have someone develop it on a fixed schedule for a fixed price.

It’s tempting for company managers to tell their development staff what their needs are and then expect that staff to go away for a while with a system that satisfies those needs. But this mode of operation leads to poor quality and failure.”

Martin carries on to describe a A large, multi-year, half-million-line project that he has had;

“The development team, were paid a relatively low monthly rate. Large payouts were made when the team delivered certain large blocks of functionality. Those blocks were not specified in detail by the contact. Rather, the contract stated that the payout would be made for a block when the block passed the customer’s acceptance test. The details of those acceptance tests were not specified in the contract.

During the course of the project, the team worked very closely with the customer. It released the software almost every Friday. By Monday or Tuesday of the following week, the customer had a list of changes for the team to put into the software. The team prioritized those changes together and then scheduled them into subsequent weeks. The customer worked so closely with the team that acceptance tests were never an issue. The customer knew when a block of functionality satisfied their needs, because they watched it evolve from week to week.

The requirements for this project were in a continual state of flux. Major changes were not uncommon. Whole blocks of functionality were removed and others inserted. And yet the contract, and the project survived and succeeded.

The key to this success was the intense collaboration with the customer and a contract that governed that collaboration rather than trying to specify the details of scope and schedule for a fixed cost.

This is a very succinct account of how the project went on, it just makes sense to me.We talk about early customer involvement in the project all the time. But, seldom, people talk about how this should be done, and this accounts explains it well.

I do have a few of doubts about it though,

A release cycle of one week for a “large, multi-year, million line project” seems a bit too tight to me. Thinking of shipping code from development to testing then to customers within a week, it’s just unrealistic for the size of the project as it sounds. Unless the functionalities were broken down to really small pieces and only a few of these pieces are included in one cycle. Or they just had LOTS of man power that can turn around a large chuck of functionalities within a matter of a week. What’s your thought on this?

Another concern is; If this “a contract that specifies the cost, schedule and requirement is fundamentally flawed. The requirements for this project were in a continual state of flux throughout the course of the project.” claims hold, doesn’t it sound like entering a Marathon race without knowing how long the entire course is and what the route condition is like? Or building a highway between two random coordinates in the Amazon without knowing what exactly are in between these two points? i.e.; The customer would have no way of budgeting for a project’s cost and scheduling for it, and just how many customers can do this??? Certainly not the corporates with a responsible CFO. What do you think?

Lastly, what would this “relatively low monthly rate” cover? All the man power (i.e.; chargeable hours) for that month? If so, what is in this “large pay out when when a major functionalities are delivered”?

4. Responding to change over following a plan.

“The ability to response to change often determines the success or failure of a software project. The course of software project cannot be planned very far into the future for two reasons. First, requirements WILL change. Second, development team aren’t good at estimating how long things will take to develop, especially for far-into-the-future tasks.

It is tempting for novice managers to create and tape to the wall a nice PERT or Gantt char of the whole project. They may feel that this chart gives them control over the project. Cross out tasks that are completed, react to any discrepancies in schedule. But in reality, structure of the chart degrades over time as the team gains knowledge about the system and the customer gains knowledge about the team’s needs. Certain tasks on the chart will become unnecessary, Other tasks will be discovered and will need to be added. The plan will undergo changes in shape, not only in dates.

A better planning strategy is to make detailed plans for the next week, rough plans for the next 3 months, and extremely crude plans beyond that. The benefit of  this decreasing resolution strategy is only the immediate tasks are planned in detail which is difficult to change, all the rest is flexible and open to changes.”

But the question is, how crude the plan is beyond the immediate future? Is it good enough give everyone, the customers and development team, an overall vision, and direction that this project is progressing towards? I am not absolutely against a PERT or Gantt diagram, because it gives you the complete picture of the project at the time. Yes, I agree that the structure of these diagrams will get changed and all. But that’s the best we get with the best of our knowledge at the time. I remember from an enterprise systems course I took at university, the 3 pillars of the course were “Goal driven strategies, strategy driven processes and process driven systems”. I guess it doesn’t matter what planning strategies we have in place, crude or charts. What’s important is, this planning is detailed/crude enough to reflects on the goal, vision of the business and ultimately software we are building. What do you think???


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: