As a transformation coach/consultant, one of the questions that get most frequently when talking to the program and accounts is, Okay; even if we implement some of these agile practices (yes practices, they don't talk about culture, values, principles, and mindset yet) internally for our technical delivery teams how do we take this to our customers?
Our customers are not asking us to be agile. They do not want to change. We see the risk if we try to impose the internal drives/initiatives on them. And many more !!
And even if we think to initiate these conversations with them how do we manage the contracts with them? Commercial agreements? Pricing policy? Engagement model and so on.
Here are some of my views based on my reading, learning, and experience so far on this transformation journey.
What is a Contract?
The contract defines the playing rules, which in turn drive people's behavior.
Why a Contract (or what goes in the contract)?
If your assumptions were correct, then you get the return or other benefits you hoped for. If not, your time has been wasted and your money is lost.
What are some of the risks?
What if you don’t have to wait for the entire duration of the project to get the delivery? And you get small deliveries frequently and validate the usability.
While there are other factors, the cost usually depends mostly on the number of people involved and on the length of the project. A fixed price is easy to achieve if you limit the time on the project but leave the scope open and definable in the project.
Obviously, getting everything would have been the best solution, but if you had to choose between ‘things for next week’ and ‘things for tonight’, which is more important? Which alternative gives you better options?
Risk Handling in Agile
Being on time with the most important features is usually better than being late with all the features
BID (RFP/RFI/RFQ) And Estimations
If they don’t play the game, they can’t get the business. Their relationship starts with a lie.
Will supplier focus on technical excellence and internal quality in fixed price engagement (technical debts)?
What Agile Contract might look like
From a contracting point of view, any contract that requires fixed scope is either non-agile or fake agile
The best way to know you can release at the deadline is to have released two weeks before the deadline. And two weeks before that. And two weeks before that.
Which projects are right for Agile Contract?
Engineering type of project. How can you tell if your project fits into the category of engineering projects? Here are some tests:
If the problem you are trying to solve requires an agile approach, the side-effects of applying a non-agile or fake agile approach will likely be a cumbersome and expensive “change request process” and a product that “misses its target market”
If the contract constrains the ability to implement improvements (review and retrospective), it will also limit “Team Performance” to a sub-optimal level and eventually impacts the motivation of the team and everyone else involved in the transformation initiative.
We (our needs, our society, our customers, technology, business dynamics, and the list goes on) are going through huge transformations where things are changing very fast. And the only way to survive and thrive is through "Continuous Customer Collaboration" (CCC)
I would love to hear your comments.
You may also be interested in this webinar recording where we explored agile contract.