13

The company I work within is tentatively moving towards an Agile project management strategy - having experienced the "joys" of waterfall one time to many. Key to this is a shift in emphasis towards delivering functionality as opposed to meeting hard deadlines.

While the development process and client relationship has certainly improved by the iterative releases fostered through Agile , it is proving somewhat harder to apply the same rationale to the funding strategies for the project. Clients are often unaccustomed to concepts like Agile, and express great concern with what they percieve as a case of "it'll be ready when it's ready".

I would like to hear people's thoughts and experiences in funding Agile projects

edit: I want to stress that I am not asking folks to explain the pros and cons of the Agile method to me, nor that I believe Agile equates to "it'll be ready when it's ready", this is a fear expressed by the clients/businesses I've worked with when advocating Agile development practices.

What I am interested in is the experiences people have had resolving the conflicts between "traditional" waterfall budgeting methods entrenched in business client/relationships and more progressive development methods - and the budgeting strategies they have adopted to support that evolution.

Improve this question
1
  • 2
    Lisa Crispin and David Norton from Gartner have some good ideas about "Selling Agile." Take a look at what they have to say: bit.ly/rlRF4U
    – Agile Scout
    Jul 27, 2011 at 22:11

7 Answers 7

Reset to default
4

If you have been able to give a quote on a project with an exact final date on all the features, why did you switch to an agile approach? You and everyone else struggles with this and an agile approach is being up front with this fact. Use it as propaganda against the competition. Southwest Airline doesn't promise you an isle seat like everyone else who does and then gives it to someone else.

Of course the client wants an exact ending date. They want inexpensive, bug-free software delivered ahead of time regardless of any changes to the original request. Tell you sales team to learn how to sell a project using agile principles. The more interations you go through the closer you can get to knowing when the project will be finished. The client also learns to factor the effects of change requests.

Improve this answer
1
  • "Tell you sales team to learn how to sell a project using agile principles" - I'll give it my best shot... {;)
    – sunwukung
    Jul 27, 2011 at 15:47
5

Agile projects don't work along the lines of "it'll be ready when it's ready". That is a classical line from waterfall engineering.

Agile projects are complete when the customer decides that he doesn't want to spend any more money on additional features. That could be converted into a key selling point by your sales people. Instead of committing to a fixed set of features (the need for which may or may not be known upfront) for a fixed amount of money, the customer can start out with an initial amount for an initial feature set and then take it in stages. This will guarantee a couple of things:

  • As long as the feature list is properly prioritized, the customer always gets the next most important features delivered next, thereby maximising his benefit from his spend (he gets "the biggest bang for his bucks").
  • If the customer runs out of money, he has maximised his investment AND you have been paid for what you have delivered. Nobody gets hurt, everybody profits.
  • The customer can change his mind about priorities and features at every turn of the wheel (every end of an interation). A distinct advantage over normal fixed price contracts.

There's probably more, but the above should be enough to get your sales people going in the right direction.

Improve this answer
2
  • Re: "Nobody gets hurt, everybody profits" - Except for the guy who got fired because he promised his boss that for $X he would get a software package that does XYZ. Unfortunately, thanks to agile the software package only does XY. P'd off manager, fires guy who underdelivers. Maybe I've just been in entirely different industries from most agile proponents, because they can't see a problem in delivering only partial solutions to the customer. OTOH, I can't see the purpose in delivering a partial solution since odds are that makes the product pretty useless to the customer.
    – Dunk
    Jul 27, 2011 at 19:18
  • Clearly you have not yet worked in a proper agile environment, otherwise you wouldn't make this kind of remark. If XYZ is required, then XYZ will be delivered. RST and UVQ may not get delivered, but since they are of lesser priority, the customer didn't have to pay for them, either. Of course, if your developers are so far off the mark with their estimates that they can't even deliver XYZ by their own estimates, then there are lessons to be learned.
    – wolfgangsz
    Jul 28, 2011 at 0:04
3

Well, I don't see it as a case of "It'll be ready when it's ready". The agile methodology promotes offering deliverables on a regular basis, like every two weeks. That's why the client is an important and very active part of the project throughout it's life as they provide guidance in terms of how the features of your product will take shape. If anything, a client will start to see results sooner, rather than towards the end of a project, as in the waterfall approach.

As long as you reiterate the fact that the client will be an active part of the project, and that they will see the project start taking shape early, that might assure them that it isn't a case of waiting until it's done.

Improve this answer
7
  • just to be clear - I'm not saying that I believe Agile equates to the that description, but that's how clients/sales often see it. Agile's great at the iterations - but makes it hard to pin down the end of the project right?
    – sunwukung
    Jul 27, 2011 at 14:43
  • 4
    @sunwukung - Your sales team isn't selling the fact that no one can predict the end of a lengthy project with any accuracy at the very beginning.
    – JeffO
    Jul 27, 2011 at 14:58
  • I imagine the best way to get an idea for the end of the project would be to have a project planning meeting with your client and list all of the features that they want. Then you can build a full and complete project backlog. Sit down with your team and get them to fill out estimates for the entire backlog. Use these estimates as a rough guide to when your project will be finished.
    – JuniorDeveloper1208
    Jul 27, 2011 at 15:33
  • 1
    @sunwukung - No, not really, sitting and planning a backlog is a good idea for Agile as well, it's the implementation of the development process that differentiates Agile from Waterfall (Agile is more iterative). I think your main hurdle after selling Agile to your consumer is actually going to be implementing it, I've been through this a few times and it can be a painful process.
    – JuniorDeveloper1208
    Jul 27, 2011 at 15:53
  • 1
    sorry - yes, I understand - we've been using the backlog method to rough out the estimated delivery window (using Pivotal Tracker, great app btw). The tension arises from the fuzziness this method produces in terms of the discrepancy between initial milestones derived from this method, and actual ETA's once the velocity begins settling down. IMO it's all about how we handle the client relationship - but that's a somewhat political component
    – sunwukung
    Jul 27, 2011 at 16:01
2

Although the place I work does a horrible bastardization of Agile, I think customers are more likely to prefer software development in iterations than full releases.

Iterations lend themselves to individual requests by customers, in that they request something and they get it when the feature is implemented, not once it's done and all the other things that have been grouped with it for a release are also done.

I have never seen a customer say, "We want this feature, and we want to wait 8 months for it to be delivered with a bunch of other features we don't care about."

Improve this answer
2
  • 1
    This might depend on the size of the customer. I think in the case of desktop software, it's not uncommon for larger companies to not want to go through mass-reinstallation/image testing/etc. frequently and in those cases they'd prefer less frequent "releases". The developer could still go through iterations internally, though, and simply present an official cut of the application to those customers at whatever interval the customer prefers.
    – Adam Lear ♦
    Jul 27, 2011 at 15:40
  • +1 for "We want this feature, and we want to wait 8 months for it to be delivered with a bunch of other features we don't care about."
    – sunwukung
    Jul 27, 2011 at 16:06
2

How about establishing a payment cycle that is in tune with the iterations? The idea of agile is that you can only really plan and estimate in short spurts, and the push and commitment are still strong for these short cycles. So why not target funding the same way - have the clients contribute to the job with $$ at the same time they are contributing with guidance. After all, if they aren't getting what they want, they shouldn't be paying for it.

And then work out what happens on termination of a project - for example, does the client own the code, or just the executable? But that would be in line with previous waterfall-type projects.

Improve this answer
2
  • I agree with this, I suspect part of the problem for the business lies in projecting it's annual revenue (thus appeasing investors) with these "short term" funding bursts.
    – sunwukung
    Jul 27, 2011 at 16:33
  • I wonder if you can steal from a contracting model? It does add the risk of downtime if customers abruptly say "thanks but no", which should be similar to the model of contract labor?
    – bethlakshmi
    Jul 27, 2011 at 17:42
1

The idea of Agile is that you iterate fast and establish exactly what you're going to deliver at the end of each sprint, so when the 2/3/4 weeks of your sprint is up, you have tangible features in your application/project that you can present to your client and get feedback.

ETA: You could bunch up 'sprints' into 'milestones', with established deliverables, and receive payment per milestone.

Improve this answer
6
  • This is what I'm trying to promote in the business - pay for "stage gates". The key issue is the final delivery date - does the client have to relinquish that concrete final deadline?
    – sunwukung
    Jul 27, 2011 at 14:45
  • Difficult to say, after a few sprints you should be able to establish your teams velocity (Amount of work you are able to do per sprint), and proving you have a full and complete backlog (List of tasks/user stories that make up a complete project) you should be able to reasonably predict your finish date by looking at your burn downs (A chart of team velocity which you can use to extrapolate your finish date and see if you are going to be able to complete all work in the sprint).
    – JuniorDeveloper1208
    Jul 27, 2011 at 15:28
  • 2
    @sunwukung, Again you are missing the point after everybody so perfectly describes it to you. Agile guarantees that the customer gets working software at the end of every sprint. If they still want a FIRM DATE for ALL FEATURES TO BE COMPLETE then they can have that but only for the features agreed upon when they signed the deal. It is unfair and unreasonable for them to change their requirements and expect the deadline to STAY THE SAME!
    – maple_shaft ♦
    Jul 27, 2011 at 15:32
  • 1
    Well, just tell them that during development they're going to be able to view their project at the end of every sprint, always in a working state and ready for feedback, it shouldn't be a hard sell, agile is excellent.
    – JuniorDeveloper1208
    Jul 27, 2011 at 15:51
  • 1
    @sunwukung, It sounds like the company would do better if YOU represented the business arm in this case :) I don't know what you can say to the business arm to convince them what you already know. They will probably not listen to you. It unfortunately sounds like the technical side is progressing into the 21st century and the business side is in the past. This is not an easy problem and you are likely not in a position to fix this.
    – maple_shaft ♦
    Jul 27, 2011 at 16:09
1

I'm myself not convinced that you should sell a fixed project and handle Agile on your side, but rather sell iterations to your customer.

Iterations are clear to understand, and you don't mix the two concepts.

The following two documents will provide you with some information about Agile Management & sales process interactions:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.