Contracting an Agile Software Project
Man, if that isn't worthy of a book, I don't know what is...I got thinking this afternoon (the bride was a napping so my mind was wandering) about how a company needs - or should - adapt to employ an agile methodology. My main predicament is how proposals and/or contracts are written.
Currently, under a waterfall methodology, countless hours are spent devising requirements, system(s) documentation, Gantt charts and time-lines, and other various artifacts that become out of date and out-of-sync when one thing changes. All that work is all-but lost. However, it seems as though customers have almost come to expect this. An unfortunate side-effect of all this is that, in turn, the projects that are put in motion this way are extremely resistant to change and, by the time the actual development begins, problem the project was intended to solve has changed many times since the initial discovery, requirements gathering, etc...
While agile methodologies counter this problem by performing each of the phases in a waterfall methodology in iterations, it seems difficult to establish the basis for a contract that could be used between the "vendor" and the customer. Taking Scrum as an example, I realize that the Product Backlog is, in essence, the requirements document and the Sprints make up the iterations, which lead to a release. But since requirements are discovered in depth prior to and during each Sprint, they aren't as detailed as the proposal or contract that is delivered prior to starting a project employing a waterfall methodology. Sure, the argument exists that there are no guarantees that the requirements document delivered is anywhere near as accurate as what an agile methodology could produce, but it sure seems as though customers want this kind of paper work in-front of them before kicking-off the project.
I guess, as with everything else, there's a tradeoff that has to be made. The Customer has to be willing to accept that the items they've defined and prioritized in the Product Backlog (or equivalent) will be produced by the Team. However, it seems as though everyone needs to have the understanding that the Backlog is not, by any means, a requirements document. It states the functionality the Customer desires of the system and that the Team and the Customer are responsible for discovering what is required of the system to deliver that functionality. The Backlog can also serve as a rough time-line for the Customer as it will include estimates for each Backlog item and during which Sprint (iteration, etc.) it is intended to be developed. And, depending on the terms of the project, it may also serve as a gauge as to the cost of the functionality.
While I will be honest and say that I feel that this is a better approach, I'm skeptical about how a customer will react to it. There have been a lot of scenarios recently at work where a potential project exists and it's also known that the customer has a more restrictive budget...although, I guess, like everything else, it becomes the company's job to determine whether there is value in attempting to acquire a project at lower rates, etc. in order to have the source of revenue.
What a tangled web we weave...
Currently, under a waterfall methodology, countless hours are spent devising requirements, system(s) documentation, Gantt charts and time-lines, and other various artifacts that become out of date and out-of-sync when one thing changes. All that work is all-but lost. However, it seems as though customers have almost come to expect this. An unfortunate side-effect of all this is that, in turn, the projects that are put in motion this way are extremely resistant to change and, by the time the actual development begins, problem the project was intended to solve has changed many times since the initial discovery, requirements gathering, etc...
While agile methodologies counter this problem by performing each of the phases in a waterfall methodology in iterations, it seems difficult to establish the basis for a contract that could be used between the "vendor" and the customer. Taking Scrum as an example, I realize that the Product Backlog is, in essence, the requirements document and the Sprints make up the iterations, which lead to a release. But since requirements are discovered in depth prior to and during each Sprint, they aren't as detailed as the proposal or contract that is delivered prior to starting a project employing a waterfall methodology. Sure, the argument exists that there are no guarantees that the requirements document delivered is anywhere near as accurate as what an agile methodology could produce, but it sure seems as though customers want this kind of paper work in-front of them before kicking-off the project.
I guess, as with everything else, there's a tradeoff that has to be made. The Customer has to be willing to accept that the items they've defined and prioritized in the Product Backlog (or equivalent) will be produced by the Team. However, it seems as though everyone needs to have the understanding that the Backlog is not, by any means, a requirements document. It states the functionality the Customer desires of the system and that the Team and the Customer are responsible for discovering what is required of the system to deliver that functionality. The Backlog can also serve as a rough time-line for the Customer as it will include estimates for each Backlog item and during which Sprint (iteration, etc.) it is intended to be developed. And, depending on the terms of the project, it may also serve as a gauge as to the cost of the functionality.
While I will be honest and say that I feel that this is a better approach, I'm skeptical about how a customer will react to it. There have been a lot of scenarios recently at work where a potential project exists and it's also known that the customer has a more restrictive budget...although, I guess, like everything else, it becomes the company's job to determine whether there is value in attempting to acquire a project at lower rates, etc. in order to have the source of revenue.
What a tangled web we weave...
posted by Harris at
11:30 PM
0 Comments:
Post a Comment
<< Home