Dealing with Agile contracts

During the technical session that I gave during the HackersGen event about Scrum, I received one question: "If Agile and Scrum favor an iterative and incremental approach, how can we deal with the preparation of contracts?"

If the three vertexes of the Iron Triangle (Scope, Time and Budget) are not so fixed and carved into stone anymore, what can the basis of a contract be?

This is not a simple answer, but Agile and Scrum allow it possible to happen! There are many tools and ideas that can help a Commercial department dealing with Agile contracts, however we - as Scrum Masters - need to coach both the Commercial people and the Customers.

Without speaking about the theory, I would like to make an example. Let's say that a Customer wants to have chat application.

Traditional (waterfall) approach

• list all features that a chat can have (login, send text message, rich format, send media, send files with preview and many many more)
• based on this list of features, we make a contract where we fix the scope, the delivery date and the budget
• we start developing the application and we will face problems: some team members will leave, things will not be easy as we initially thought, we'll have architectural issues. and anything that the Murphy's Law will predict! :D
• This means we'll run past the delivery date, the cost of the project will be much more than what initially planned, but the scope will be pursued.
• and after all this time has passed, maybe the market doesn't want this product anymore, of the feature we developed may not be so appealing anymore

One of the possible Agile approaches

• prepare a Goal Oriented Product Roadmap, i.e. a roadmap where we say what we can build in what time (we can split the chat application into its main feature, such as "sending text messages", "sending media", "creating groups") but without getting too much in detail of the single feature
• we can then make a contract based on this roadmap
• we start developing and delivering to the Customer what we are building, so we can have their clear feedback, and make them aware of what our progress is. We can start building the features that deliver more value, such as sending a text message. But thatis it: only text message. If we have time we can make also the icing on the cake, such as adding rich-text formatting, make great shapes for the balloons etc. But they are not really essential. The main thing to give value to the Customer is make them able to send a message. All other things will come.

In conclusion, a way to make an Agile Contract may be to base it on a Product Roadmap, which doesn't list the features in detail but only the main capabilities

In this way, we are sure that our product can relieve Customer pain points, and deliver value as soon as possible!