Its been slow on this blogs front for a while now [2 months now]. This is because, I have recently joined a growing Internet Product Company, www.wiziq.com as a Product Manager. This is a great opportunity for me. As a Product Manager, I would be the marketing teams interface with development team. I would have a team of marketing people working with me and I will work with them to identify the customers real needs. We will develop as per the priorities in the market and this is a real exercise in me to become a product owner. Already I am grappling with issues like prioritizing the tasks - identifying the best process to complete the tasks in a weeks time [our sprint time] and defining the releases. I am also working with Internet Marketing team, Marketing team and Support team. An all rounded exposure would provide me a great experience to becomes a Gen-Next Product Manager.

• Technical/ Code related measures
• Business Perspective
• Process Perspective

• Code Coverage : Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing
• Cohesion : In computer programming, cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is an ordinal type of measurement and is usually expressed as “high cohesion” or “low cohesion” when being discussed. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand.
• Low Coupling: In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.
• Cyclomatic Complexity: Cyclomatic complexity is a software metric (measurement). It is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program’s source code.
• Number of unit test cases per feature or method or class. Minimum 4 test cases per feature ( +ve, -ve and stress, system interaction)
• Defect Density : Number of defects per lines of code

• .Net - nDepend
• Java - jDepend

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.

It is interesting to note that there is a company in North India, that claims to use only Agile Software Development frameworks for its IT Services Outsourcing. The company is www.xebia.com Although there home page does not talk about this, if you go to some inner pages you get mention of terms like Agile Business, Business Value, Scrum Certification Courses can be found. They are also organizing a conference in NCR on Agile.

• Do code reviews
• Define tasks
• Assign tasks
• Track tasks
• Firefight
• Make MS Project Plan
• Make Excel Reports
• Talk to the customers
• Give feedback to team members
• Recommend appraisal of team members
• Promote team members
• Give presentations
• Train people
• Write case studies
• Write white papers
• Work with other teams
• Provide technical leadership
• Provide process leadership
• Provider marketing leadership
• Do HTML coding or other housekeeping work
• Keep customer happy
• Read about technology and trends
• Make usage projections
• Improve company bottomline
• Recommend engineering practices
• Control attrition
• Interview and hire
• Provide status updates

There can be more depending on which organization do you work with. All that is needed is to come up with all the tasks that you do and cross out ones you should not do in Agile. Assigning and tracking tasks are obvious ones to go. There are many above that can be crossed. After this, investigate if any more things should be added to the mix. Thats it - you have a great new JD for a Manager. CMMi - here we come

• We do not know how to bill - the customer wants a fixed price while we can’t give it in Agile
• We do not know how to hire - there are so many things we need to look for more, we can’t seem to find enough people
• We do not know how to train - we need to coach people on things like responsibility, duties and collaboration
• We do not know how to measure - how can you measure without knowing what everyone else did
• We do not know how to manage requirements - they just keeping all the time and we do not know how to keep architecture scalable for that
• We do not know how to manage - Agile just throws so many things in diverse directions and we do not know how to go about things

The Norwegian Computer Society now offers a complete set of standard contracts for software development and maintenance and management. The standard contracts are now being used in many of the largest public IT projects in Norway. The main feature of the contract for software development is that:

• It provides mechanisms for establishing a common understanding between customer and the developer and
• A flexible iterative model for development suited for an environment of uncertainties and risks

The standard contract for iterative development [v2] has these main elements:

• Increasing efficiency of the procurement and tender processes
• Based on documented “Best practice”
• Tools for managing uncertainty
• Stage by stage, iterative development model securing ability to benefit from increasing understanding of the requirements and challenges
• Close co-operation between supplier and customer
• Incentives and sanctions in combination with target pricing
• Procedures for conflict resolution with an expert as a mediator

The contract consists of three parts:

1. The Customer and Supplier are defined in the Part I, Contract Document, which also sets forth the order of priority between Part I, Part II and the annexes in Part III.
2. The General Provisions are stated in Part II. The objective of Part II is to govern the rights and obligations of the parties in relation to the development of the software, including any adaptations, services and associated hardware as specified in separate annexes (Part III) to the Contract.
3. Part III consists of all the specific annexes.

The difference between a normal contract and this contract is that it outlines terms of engagement clearly. Instead of providing an overall project cost, the team estimates one iteration at a time and each iteration is almost a new project.  Hence, the contract basically takes the incremental approach to estimation as well. Apart from this, the team also outlines the responsibilities, roles and rights of the supplier and vendor for the success of the project, primarily that customer would be responsible for marketing insights and the developer for the technical insights. An expert is pre-selected as an arbitrator in case of dispute. Just the fact that you follow an iterative model for estimation, you improve the efficiency of standard contractual cycle by:

• It takes assumptions, forecast and psychic part of estimation out
• Allows for Agile development to emerge automatically
• Closer cooperation and collaboration needed by default
• Incentives and sanctions along with target pricing can provide a nice framework for iterative development

I am trying to get my hands on one such contract and lets see if we can analyze this further.