Went to a good session on SCRUM this afternoon by Edwin Dando from Clarus and it re-enforced to me the real challenges of applying a SCRUM process to my clients.
Lots has been written about the Project Triangle.
The basic idea is the quality of a solution is maintained by balancing the competing dimensions of Money, Scope and Time. For example, if Scope increases then it could impact on Time (you need more) or Money (you need to throw more at it to get more resources perhaps).
SCRUM is based on the premise that Time and Money are often fixed and that to maintain quality it is Scope that needs to budge. This is further reinforced by the idea that Scope is rarely fully understood anyway at the start of the project so is bound to change anyway.
Well here's the rub. A lot of our clients come to us with, what they consider, to be fairly complete requirements. They go to tender, with their requirements documented, and ask for fixed price responses.
So if Vendor 1 comes along and says,
I can do all you want for $X.
and Vendor 2 says,
I will do as much as I can for $X.
I'm thinking Vendor 1 is looking pretty good. Vendor 2 with SCRUM in their eyes hasn't got a show!
Let's assume the client really did know what they wanted. This means Scope and Money will be fixed. In my experience, despite what clients say initially, timelines are often the easiest things to change (just look at Microsoft shipping dates!). So a client can still get the quality they expect for the price they were quoted. Client will always win and Vendor 1 could loose out big time if the project drags on unexpectedly. With Vendor 2 the client could end up with only a subset of their requirements. The Vendor has essentially said they aren't guaranteeing implementing all requirements.
If Scope does change the client can still weigh up the impact of making the changes - even exchange features for the new ones (much like the SCRUM approach). As long as Vendor 1 is honest the client is still getting the best of both worlds. Of course, the risk here is that Vendor 1 will inflate CR estimates ultimately costing the client more.
What's even more compelling for the client is that potential Vendors will bid against each other to make their offers as attractive as possible - this will result in multiple Vendor 1 style responses and reducing Vendor 2's chances even further.
So - assuming there are lots of Vendor 1 style responses out there - how do you sell the advantages of SCRUM? Unfortunately I don't have the answer but would love to hear from others that may.
To close, one of the problems is that SCRUM (and many other Agile practices and methodologies) were created to solved product based developments rather than service based ones as I've described here. When you're building a product, the 'client' is often someone within your own company - you get the trust relationship by default. You also aren't competing for the work with other vendors. I'm hoping we see more industry thought in this space and look forward to ideas it make clients and vendor's lives easier in the service industry.