how to manage an agile project with a third party

Question

As a programmer I'm all in favour of the agile methodology, we all know it makes sence, however how do you sell this to a third party ?.

The work we do is generally fixed price and it is usual for us to only have a high level view of the requirements when we quote as it is often a competitive situation. We often find that when we win a contract and get to look at the detail the features grow in scope. While we do have a mechanism for managing this scope creep it is not robust and transparent enough which commonly results in us conceding days.

The agile methodology may say there is no such thing as scope creep, however in the real world we all know there is. When a customer asks you to provide a solution, at a fixed price and time scale (which they always will), and then change the goal posts mid-project that is scope creep. At the end of their budget they will quite likely to be left with something different then they originally intended and which may not fully meet their original requirements. At that point they’re going to come back and argue that they've not got what they paid for - the only protection we have against that is a spec that lays out exactly what they're going to get up front that we can deliver against, clearly not the agile way.

I know people will say the customer should be kept informed at all times as to what they're getting and what's being moved out of scope blah blah blah...- however in the REAL world as far as I can see you'll always get a customers who will then say at the end - this isn't what you promised to deliver / we've paid for. How do we manage that situation?.

Answer 1

Maintain a burndown chart of the project.

When they see it, they will get it. They will know the projects velocity and they will see the implications of scope creep. They may also see the value of scope reduction by pruning low priority items.

Burndown charts is a way keeping you and your customer informed. Once you both see the Big Picture, you can negotiate how to move ahead--fairly.

This video is a good case study.

Answer 2

This is where some of the concepts of SCRUM pay off.

1. The business leader MUST be involved with every step of the process.
2. Picking which stories make a particular sprint MUST be done with the business leader.
3. Don't do anything in a sprint that is not scheduled for that sprint without adding it to the sprint backlog chart for that sprint. It's good to show things that were added to a sprint in a different color. That way you can see the original plan (hopefully on schedule) and the additions (what causes the delay).
4. Produce something that "could go to production" in each sprint. The business will see that it's getting something for their money. They can also adjust future sprints based on what they see. Each sprint makes a good stopping point.

-- EDIT --
Hmmm. Maybe a DVD of the video Ray suggested (or this one) should be included in the project proposal. It might make the difference when trying to get the job to begin with. The customer should know how your group works BEFORE they hire you. It will make your company stand out as more than just a "body shop".

If you ARE a "body shop"...
1. You probably won't be able to wield much control over how the project goes. You'll be collecting the hours.
2. If you see the project going badly, start dropping hints to the client "If MY company were running this project...". You may get the next project!

Answer 3

You cannot do agile project without customer buy-in.
And you won't have customer buy-in to your preferred approach if they don't understand why their approach is flawed.
You have to educate the customer about software development challenges and methodologies.
Even if it's time consuming and not guaranteed to succeed.

(Or you can go with the flow and try to develop software with fixed schedule and fixed budget and growing scope which we all know is impossible, but that will only lead to problems you described above.)

Answer 4

a spec that lays out exactly what they're going to get up front that we can deliver against

is a fairy tale. Never seen one, never will. The only thing it is is a creator of a lose-lose situation. The first thing to do is to start naming things by their real name. A fairy tale is a fairy tale, even if it is called a spec