Discouraging Waterfall contracts

I know thats a rather sadistic title for a post but I could not help write the same. For the purpose of this post, I consider Waterfall as “fixed scope” project more than a reasonable length [4 person man months and over should quality I guess]. Here are some things you can try [some have worked like magic for me]:

1. As bad as it sounds, add even more ceremony to your waterfall contracts. Add initial requirement list sign off, each requirement gathering iteration sign off, method of estimation sign off and what not. Try to get sign off on exact process, SLA, bug count, delivery dates, feedback latency and all the abstruse things any one can think of. If that does not help, announce that after subjecting the poor client to 1 month of requirement gathering and contract revision, you plan to spend another 3 months discussing the project itself. The above time zones [1 month, 3 months] are relative for say a 6 month project. If that also would not work, try adding clauses that favour development unit more than the client - “All UAT must be done within 2 weeks of getting the build and the like.” Add costs for any allowance the client requests. You will either loose the business or get an opportunity to push fixed cost/ fixed time but variable scope projects. If you can just send an email newsletter singing paeons of Agile just at right moment to get the clients in right mood to talk.
2. Disguise Agile Completely. Here is one approach:
   • We understand initial requirement define a fuzzy viewpoint on the horizon. Hence, we allow our customers to add requirements at any stage and delete/ edit/ replace items from the requirement list as long as it is of the same size, size determined by us.
   • We would provide you working software every iteration [basically 2 weeks/ 2 months] free of cost/ at additional charge of XX USD per iteration.
   • You can cancel the project at any stage for a free of XX USD in case your business interests are met earlier due to working on prioritized business requirements
   • We welcome client feedback and this would be managed as per attached Annexure [Annexure is more glorious description of SCRUM/ Agile].
3. If the above slightly cheeky ideas don’t work for you, you can simply do case studies of projects done using Agile [also do customer satisfaction studies] and show how going Agile is good for business [faster time to market, lower cost of ownership, flexibility to respond to business changes] etc.

Agile Contracts - Approach Two

We discussed a Traditional Approach to Agile Contracts in the previous post. In this post, we discuss a slightly more Pragmatic Approach, that keeps with the spirit and letter of Agile but you can expect slightly more bickering here. However, its still better than the traditional fixed price approach. So, here is what we have been trying.

• Estimate like any fixed price project
• Make a project backlog - as detailed and as accurately as you can at a time
• Estimate in real time units each item in backlog [no relative units like story points]
• Allow customers to change stories that team has not started working on from future sprints with same weight stories [weightage estimated by the team]
• Provide working software at the end of every release
• Ability to cancel future sprints at a given pre-project cancellation fee

The only real problem that this kind of approach brings is that after the first few sprints, keeping track of what can be taken out and inserted needs a bit more analysis and discussion than a traditional Agile team would like. Another side disadvantage can be to not implement proper SCRUM/ Agile rules [as you are doing fixed price]. Hence, you need to add a fixed time dimension for this which unless estimated carefully can be a double edged sword. The advantage of this approach is that you can readily sell this to the clients and sort of marry Agile with fixed price approach very well. We have started this approach with two recent projects and would like to see how this goes.

Agile Contracts - Approach One

A lot of people responded back on the SCRUM Development Group to the discussion on Penalities and SCRUM. After having discussed this topic over the last two months, I personally feel [and thats with that big "I" again], the discussion on Penalities and Agile/ SCRUM is probably a subset of the overall domain which can be called “Agile Contracts“, which you can construct in different ways. Here is one approach which we have tried to follow. As the projects are currently on, its a bit too early to get to the efficacy of the approach. However, there are some early trends which are provided without bias below.

I call this approach “Traditional Approach“. This is in keeping with the letter as well as spirit of Agile. It assumes:

• Evolving requirements
• No upfront estimation [in hours] - ok I made this one up, its not really an Agile value, but well we like it
• Transparency and effective reporting
• Client Collaboration

The Contract is noticable because there is hardly anything there. Its a bit like the old “Times and Materials Contract” with focus on:

• Project Reporting - backlogs, burndown charts
• Communication Means
• Service Levels
• Types of services covered [designs/ HTML/ dot.Net coding/ QC]

The contract continues for a year at a fixed hourly rate. After a year, you can negotiate a higher hourly rate especially if you score consistently on service levels.

The problem really is that despite its simplicity, it is difficult to sell this to the clients, especially new clients. It can however work in the following situations:

• Existing client, fed up with fixed price approach but generally happy with service
• Existing time and materials client
• Prototypes/ proof of concept projects
• You can use your internal knowledge management system to demonstrate expertise in particular area

We have had great success with this contract [this was not the only thing but contributed significantly to relieving pressure on team and clint] with a client of ours [the client whom I explained SCRUM and posted transcript here]. The team has consistently exceeded client expectations. One of the reasons they attribute this to is “willingness to not haggle on what is covered and what not in contract” and just think of one sprint/ release at a time. The customer is very happy and we have not heard about the project for a while now and that means it is going really well. The approach has a great advantage for all parties. If you can find any disadvantage [other than difficulty in selling the approach], please do leave a comment.

Penalities and SCRUM/ Agile

We have converted quite a lot of our projects and teams to Agile which is great. The teams are happier and delivering value to customers. However, one area where we have a problem is with new customers.

New customers appreciate and value the flexibility Agile offers but would like to stick to a deadline [October 15 or December 15]. We always advise and agree them that this is a central part of Agile - aiming for delivering maximum functionality by given deadline. However, what is a problem is that they take the release date as being a bit too literal. They would even like a penalty for not completing the project by given date. And these are pretty knowledgeable clients who are pretty reasonable otherwise. We try and reason that with ability to prioritize, shelve and add features that Agile offers, this kind of clause is not possible. However, it does not cut much ice with them.

We have tried to convince management to add a bonus clause [if we meet target we would bill at higher rate and client will finance holiday for whole team]. Surprisingly the clients agree to this and the ball is back in our court. Further, the teams internally do not want to go in projects even with lure of bonus and no amount of convincing helps them. They say they can commit to the deadline only if all UML and prototype diagramming has been completed and signed off. This gives us ideas and scares of waterfall ghosts.

As always, its an interesting problem to have and something we need to plan out on how we would approach.