5

I have a client that's requested a detailed Scope of Work/Statement of Work. Upon looking into it, it seems they want timelines, costs, features, the whole nine.

In order to do a detailed SOW, one basically has to have the whole system planned out ahead of time.

Yet, the customer is not happy with any development approach other than Agile.

Seems to me, either:

  1. A detailed SOW = Waterfall approach, or
  2. A detailed SOW continuously needs to be updated when taking an Agile approach, in which case the "detail" of the SOW seems awfully pointless.

I'm not really a big shop, and it seems to me that putting together a detailed SOW (especially after explaining that estimates are difficult for all the reasons we know estimates are difficult) with timelines and costs, and further maintaining it through an iterative/revisit often approach seems like a whole lot of overhead.

On the flip side, a much more general SOW with some grey area in the detail seems much more appropriate and easier to maintain, however this isn't the impression I get when I read up on what an SOW should contain.

How do you balance a detailed SOW with an agile approach? And does it seem correct to say that a detailed SOW is veering toward a waterfall approach to things?

(I might note that I never work on fixed-bid pricing, all is hourly, just because...)

jleach
  • 2,632
  • 9
  • 27
  • You can start by building a simple prototype / sketches as a deliverable. Charge for that work and work in the same agile way as you would normally do so they get in the flow. Then after delivery of the sketches with desired features you can together agree on where to start. – Luc Franken Apr 10 '16 at 07:44
  • 2
    Have you asked your client about the apparent conflict (between agile and his desire for waterfall), and how he intends to resolve it? – Robert Harvey Apr 10 '16 at 15:09
  • Many clients need an overall project estimate, and playing waterfall v agile will not be received well. If you have too many unknowns to come up with an estimate, then break out the project into a couple earlier milestones and provide estimates for them. Include revised estimates throughout the project. – William Walseth Apr 10 '16 at 19:14
  • @RobertHarvey - I haven't yet, figured I'd check and make sure I wasn't missing something myself first. – jleach Apr 10 '16 at 19:26
  • @WilliamWalseth - I don't have an issue with the estimate, I can do (and have done) that, and revised estimates are generally a given. My concern is specifically that they wanted a detailed SOW, but a detailed SOW basically sounds like a Waterfall spec to me. – jleach Apr 10 '16 at 19:30
  • jd, is the spec really that different between agile and waterfall? How you handle this really depends on the customer and your relationship with them which is way more important than agile v waterfall – William Walseth Apr 10 '16 at 19:48

1 Answers1

1

Agile doesn't preclude you from having a plan/requirements upfront. It precludes you from assuming that those plans won't change.

It also doesn't preclude you from having a deadline. We all have deadlines. It does however, give you an earlier sense than waterfall development of where you stand with regards to meeting that deadline with the desired requirements, since at the end of each sprint, you have a "shippable product" and can gauge how far you are from the finish line.

Martin Fowler describes a way to deal with this that he calls Scope Limbering.

The key to this is this line:

... from the beginning we sought to put the relationship between our companies on a collaborative note rather than a confrontational note. The biggest problem with the fixed scope contract is it immediately pits the client and contractor on opposite sides where they are fighting each other about whether something is a change and who should pay for the change.

(emphasis mine)

What Fowler did when facing a situation almost exactly like yours was to build a buffer into your quote, then work very closely with the client (which you should be doing anyway) to demonstrate to them how much the requirements change as the process goes on.

Greg Bair
  • 345
  • 3
  • 10