We do not know how to …

A lot of people come to me these days and ask, ever since we started doing Agile, things have gone from bad to worse. Some of the things that go wrong [according to them] are:

• 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

My first response to this is “Ok! At least you know all this and got so far”. Invariably I find out that the reason they are unable to manage the above is because they are able to somehow manage to do the impossible - reinvent the wheel on Scrum and XP. Probably its the comfort of familiar rather than uncomfort of unfamiliar, although that may turn out more comfortable. Needless to say there are many solutions available for the above. We will try and see some of them in the future posts.

PS 2000 Contracts for Software Development

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.

The Purpose of Scrum

I came across a very rare piece of information. It is an article of Ken on “the purpose of Scrum“.

“Work is an ennobling experience, an affirmation of life. In teams, the experience transcends the individual, encompassing the shared experience, providing the basis for team heroics.

Scrum brings order, clarity, cohesion, stability, flexibility and –ultimately – success to projects. In organizations that are coping with how to organize and compete in today’s new economy, Scrum provides a civilized means of rapidly bringing new, complex, high-technology products to market.

Scrum enables people to work harmoniously for their mutual benefit while producing some of today’s must complex, sophisticated products. Scrum is the social engineering of today’s enterprise for the co-operative fulfillment of all involved.”