Archive for Agile Collaboration Schemas

Business Alignment over Engineering Features

Posted in Agile, Collaboration with tags , , , on November 18, 2008 by vikramadhiman

In his blog on Product Management, Saeed proposes a fifth element to the Agile Manifesto:

Business Alignment over Engineering Features

His argument is that developers, testers and even managers treat each feature equally without worrying about how the business makes money. There were some interesting responses to this:

1. Jelena said that this is already contained in the Principles “Business people and developers must work together daily throughout the project”, and also can be filed under “Customer collaboration over contract negotiation” element of the Agile manifesto. She also goes on to say that sometimes engineering excellence is more important.

2. Others illustrated how product management and development can never reconcile.

I don’t think it is needed to have another element to the manifesto at all. As Jelena said, it is already contained in the principles and also in the elements. If a  Product Owner can not make efficient decisions and guide the roadmap, then the team can’t do anything. For instance, in the firm I work with currently, the Product Managers and Development Managers blend so effortlessely that you wont even notice, who is who. This closely aligns the business with the development. We prioritize, reprioritize vigorously and we make decisions collectively – sometimes development helps us make better decisions [what if we just made a single HTML page rather than all dynamic feature that you want and will take time] and sometimes businesses help development make better decisions [we need a guarantee that whatever was working before is working in future].

In essence, elements basically highlighted the importance of where our focus should be. Business Alignment over Engineering Features places a lot more emphasis on Business Alignment and takes the focus away from Engineering Features. This is also partly wrong – engineering features and excellence in itself is also sometimes desirable.


Agile Collaboration Schemas

Posted in Contracts with tags on March 19, 2008 by vikramadhiman

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/3rd – 2/3rd 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.