I was inspired by Dr. Brene Brown Ted talk here about vulnerability when writing this post. Instead of control and predict the way to live is vulnerability, that’s how I got it.
I am helping a team who sub-contracted remote vendor for fixed scope, fixed price and fixed schedule (FFF) development. The team asked the vendor to follow 2-weeks sprints so that it can have demo and plan the work for next sprint.
The team addressed risks as follows:
– Added penalty clauses for delays
– The sub-contractor is willing to do what it takes to succeed in order to have repeatable business
– The sub-contractor has estimated the requirements
Not the large requirements document and fixed price, the highest risk was the “protective” language and atmosphere which surrounded this contract. For me this is the receipe to project death march, because:
– Protection leverage the value of contract rather building trustful relationship
– Protection encourages finger-pointing
– Protection promotes wordy requirements document which might not carry enough business value to the organization
– Protection is a gate to change control, approval and more tension in relationships
FFF contracts are used for situations when:
– Customer exactly know what they want
– Seller has complete ability to deliver and has repeatedly done that before
– No change will occur through course of the project
For me the above three points are seldom happening in software development especially if we are talking about using new technology. The Agile model, from my view, has been created to mitigate the risks associated with these three assumptions. The reason to embark in such risky contract, from the team view point, is to have cost ceiling. For me this is the second higher risk. This is because technology is new and the customer will not be able to assess quality aspects of the code. Therefore, if the vendor loosens the quality rigor in order to meet the deadline, the customer would inherit technical debt.
Protection for me is a tool to handle project in highly distrustful set-ups which management does not have the courage to change to cope with the true spirit of becoming Agile. Such management ends having Agile implementation as title while not achieving the real benefits of delivering high value to its stakeholders, employees and clients. What about if the vendor failed to meet what is required at the end of the 4 months contract period? Simply, we lost opportunity of being first in the market.
Alternative way to this contract, if I were management, is summarized as follows.
- Assign product owner to work closely with the vendor. Hold the product owner responsible in arriving at prioritize features with their US$ value. She should create stories to mitigate risk of technical debt.
- Shorten review cycle to weekly.
- Engage with vendor on weekly billing basis, this minimizes the risk of losing work to maximum of one week.
- Provide the vendor with the stories of the high valued features and have the product owner involved in clarification, review, assessment, planning and retrospective.
The second approach is simpler than FFF while it promotes:
- Trust relationship
- Little focus on contracting while focus is shifted to delivery and quality
- Change is embedded in the process
- We the customer assume responsibility in front of senior management on the product instead of risk transfer to vendor
- Effective risk mitigation as the maximum we can lose is one week of effort instead of potential 4 months loss
- Control the technical debt
Vulnerability rather being weakness, it’s enabler to expose issues and reduce contention relationship which is not uncommon in contracting environment, especially those which are FFF based. The process is not meant to protect customer from vendor, rather to build trust by having each party is vulnerable to some extent so that we can collaborate to solve product issues. The above post describes true story of contract which has been in preparation for 3 months and to be delivered in 4 months while choosing FFF model. Unless management can transcend to vulnerability, for me, it’s not easy to obtain the Agile benefits of bringing true value to the organization, its employees and stakeholders.