We can’t bid on contracts on the basis of doing Scrum as Sales believe they won’t win any contracts. We’re doing Scrum, however, because we believe it increases our changes of delivering. So we’re doing Stealth Scrum in that we won’t explicitly tell the customers about it. We’ve identified a number of ways of creating a contract that can work with Scrum and will be acceptable to our customers.
Time and Materials (T&M) in the terms, perhaps around the installation, can allow for some incremental releases. The bulk of the contract can still be fixed price and the T&M can be budgeted. That way the customer can get sign-off on the budget and we have some room in which to be Agile.
Release points in the contract are so the customer gets early insight into the product. They’ll certainly have feedback and then the functionality may be renegotiated. Done on a capability in, capability out basis the budget need not be changed (which will save a lot of headaches for them as they don’t then need to go and talk to Accounts). If we release Minimum Marketable Features (MMF) early the customer has plenty of opportunity to get involved.
In the contract we talk about how we are going to work with the customer. If regular access to a customer representative can be negotiated then they can be regularly reviewing progress, both catching mis-steps early and also preventing the Team doing work that won’t be accepted or isn’t required. The better communication with the customer will improve the trust between us and them.
Change Requests (CRs) can be created that the customer may, or may not, pay for. Even though the contract will have the functional specification stapled onto the back it’s understood that change must be managed. Stating goals for the project will hopefully guide negotiations around scope creep. CRs are a tricky area as it can damage the trust between ourselves and our customer if not handled sensitively.
We do a Design Study before software construction commences. The customer is guided as to what a Design Study constitutes so that what they expect from it matches closely the coarse-grained estimates you’d expect at this stage. This will minimise the normal contract practices of cost padding and caveats.
Scrum handles what project risk it can through reprioritisation of the product backlog, raising riskier workitems to the top. This needn’t be raised to the customer unless we now suspect something is going all the way to the freezer [front-burner, back-burner, fridge, freezer]. Other project risk has to be addressed through standard project management techniques.
Scrum can manage risk through the trust that is built up between the customer and the team. The customer accepts that the team will do their absolute best to deliver business value as fast as they can and pays for the time required to make the delivery. The team does everything in their power to be transparent so that the customer knows exactly what to expect and can be comfortable that they are getting value. This trust can be difficult to achieve when attempting Stealth Scrum.