Agile Collaboration Schemas

Traditionally, Indian IT Services Industry has a tradition of negotiating contracts and these contracts define the nature of association between the organization outsourcing work and the organization taking on work.  However, traditional mechanism of contracts is undergoing a change as at one end the IT Industry has entered the third wave of services characterized by core technical skills, strong project management skills, creativity and innovation and on the other hand competition is increasing. The sellers market is slowly being replaced with buyers market. In addition, whether the organizations are doing “Agile” or not, Agile is also influencing how contracts are structured. Agile contracts are perhaps the most important facet in a service organization looking to go Agile. If the organization can’t have a contractual structure in place, more than likely Agile implementation would fail. However, it takes a bit of learning and unlearning to understand how to write contracts. One of the first things to do could be to call it by a different name. I like to call them “collaboration schemas”. Here are broad differences between contracts and collaboration schemas:

• Like Agile, collaboration schemas define the broad contours and framework of engagement
• Like Agile, each collaboration schema instance is unique and different
• Like Agile, collaboration schemas are to come up using collaboration, feedback and trust
• Like Agile, collaboration schemas emphasize transparency and minimize capitalizing at others expense
• The outcomes of the collaboration schema is Keiretsu – closely knit organizational engagement

A major factor to consider moving forward in Agile is trust. Trust is one of those values which you can only earn through your actions. Trust is formed right from the first interaction and continues to be either strengthened, holds on or declines with each further interaction.  These principles help a trust worthy image for the company:

• Open negotiation of profit margins
• Transparency on actual costs for development
• Ability to walk the extra mile and think what’s the best for the customer

Another of the salient features of contracts is the “fixed price”. Everyone dreads “fixed price” in service industry. The customer knows that she would be looking at huge change control budget even after a “fixed price”. The vendor knows that they would more than likely a loosing proposition and yet they would take it up. And on top of this, another common myth< is that you can’t do “fixed price with “Agile“. That’s not entirely true. There are various fixed price options available [and more can be constructed]. Some of these options include target cost collaboration schemas, 1/3^rd – 2/3^rd collaboration schemas, evolutionary collaboration schemas, fixed price/ fixed date collaboration schemas, maximum cost/ last date collaboration schemas, declining rate collaboration schemas and intellectual property collaboration schemas. Some other options within the framework include less scope collaboration schemas, two stage collaboration schemas, initial requirement freeze phase and fixed quota hours.  

Agile is finding wide spread acceptance and in future there would be more examples and schemas to provide reference for teams looking to try Agile within service environment. However, the above should be a good guidance and relatively risk free bases to start from for most teams. The idea is to understand that the above are just a starting point and the real beauty of Agile should be brought to collaboration schemas as well – visibility, inspection and adaptation.

Advertisement