Scott Stults
Category: Uncategorized
This Monday we were fortunate to hear Dr. Jeff Sutherland give a presentation on Scrum at our monthly Neon Guild meeting. He was going to be doing some training at Inova Solutions, but the Guild got a great overview of Scrum as an added bonus.
One of the difficulties Dr. Sutherland touched on during his presentation was introducing Scrum to managers who only know of the “waterfall” method of running projects. I think this mainly impacts contracting organizations at two key points: Requirements Gathering and Delivery.
Chunking
The first challenge is to break large projects into smaller ones. Customers envision the final product with varying clarity. However, when they put their trust in an outside organization to deliver it they want to know exactly what they are going to be getting for their money. So, at the outset of a project they seek to protect their investment through rigorous requirements gathering and design phases. This gets exacerbated every time those involved go through a failed project, because smart managers seek to fix their processes and not the minutiae particular to any one project. Therefore the process that bares the brunt of their scrutiny is Requirements Gathering (and by association, Design.)I believe the key here is to show how breaking their project into smaller chunks limits their overall exposure and gives them the flexibility to adjust the project requirements as business needs change. After all, the goal of any project is to address business needs and not a particular distillation of them represented by a requirements document. The map is not the territory.
Deliverables
However, the chunking of the project must also include a modification of delivery expectations. In Waterfall projects, success is measured by three questions: Was it on time, Was it within budget, and Do all features work? What burns longer projects is the Sisyphean nature of technology, in that the features you build become obsolete as you create them. The longer it takes you to deliver, the more irrelevant the project becomes. Therefore, each subproject or Sprint addresses what the customer needs right now, rather than several months down the road. In a lot of ways this breaks the PMI definition of “project” in that the end state is less defined. But since you are incorporating change into the contract, that end state is going to be much more useful to the client.
The Contract
Which brings us to the contract itself. You will need to translate your Scrum project into a contract that will pass legal scrutiny. This means that you have to adjust traditional contracts that state “We will do X by Y for $Z.” Those contracts place little or no responsibility on the client beyond an initial requirements specification, acceptance testing, and payment. In Scrum, customer participation in the Sprint Review is essential, and belongs in the contract. One strategy could be to only contract for the initial Sprint. But if the client is already thinking Big Project, you could trade features that are contractual obligations for Sprint Reviews that are contract termination clauses. In either case, the responsibility of project “success” is going to be shared much more than in a traditional project. As compensation, “success” will no longer be check marks on a project plan but a measurable increase in business value.