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.”

Agile Contracts - Approach Two

We discussed a Traditional Approach to Agile Contracts in the previous post. In this post, we discuss a slightly more Pragmatic Approach, that keeps with the spirit and letter of Agile but you can expect slightly more bickering here. However, its still better than the traditional fixed price approach. So, here is what we have been trying.

• Estimate like any fixed price project
• Make a project backlog - as detailed and as accurately as you can at a time
• Estimate in real time units each item in backlog [no relative units like story points]
• Allow customers to change stories that team has not started working on from future sprints with same weight stories [weightage estimated by the team]
• Provide working software at the end of every release
• Ability to cancel future sprints at a given pre-project cancellation fee

The only real problem that this kind of approach brings is that after the first few sprints, keeping track of what can be taken out and inserted needs a bit more analysis and discussion than a traditional Agile team would like. Another side disadvantage can be to not implement proper SCRUM/ Agile rules [as you are doing fixed price]. Hence, you need to add a fixed time dimension for this which unless estimated carefully can be a double edged sword. The advantage of this approach is that you can readily sell this to the clients and sort of marry Agile with fixed price approach very well. We have started this approach with two recent projects and would like to see how this goes.

Agile Contracts - Approach One

A lot of people responded back on the SCRUM Development Group to the discussion on Penalities and SCRUM. After having discussed this topic over the last two months, I personally feel [and thats with that big "I" again], the discussion on Penalities and Agile/ SCRUM is probably a subset of the overall domain which can be called “Agile Contracts“, which you can construct in different ways. Here is one approach which we have tried to follow. As the projects are currently on, its a bit too early to get to the efficacy of the approach. However, there are some early trends which are provided without bias below.

I call this approach “Traditional Approach“. This is in keeping with the letter as well as spirit of Agile. It assumes:

• Evolving requirements
• No upfront estimation [in hours] - ok I made this one up, its not really an Agile value, but well we like it
• Transparency and effective reporting
• Client Collaboration

The Contract is noticable because there is hardly anything there. Its a bit like the old “Times and Materials Contract” with focus on:

• Project Reporting - backlogs, burndown charts
• Communication Means
• Service Levels
• Types of services covered [designs/ HTML/ dot.Net coding/ QC]

The contract continues for a year at a fixed hourly rate. After a year, you can negotiate a higher hourly rate especially if you score consistently on service levels.

The problem really is that despite its simplicity, it is difficult to sell this to the clients, especially new clients. It can however work in the following situations:

• Existing client, fed up with fixed price approach but generally happy with service
• Existing time and materials client
• Prototypes/ proof of concept projects
• You can use your internal knowledge management system to demonstrate expertise in particular area

We have had great success with this contract [this was not the only thing but contributed significantly to relieving pressure on team and clint] with a client of ours [the client whom I explained SCRUM and posted transcript here]. The team has consistently exceeded client expectations. One of the reasons they attribute this to is “willingness to not haggle on what is covered and what not in contract” and just think of one sprint/ release at a time. The customer is very happy and we have not heard about the project for a while now and that means it is going really well. The approach has a great advantage for all parties. If you can find any disadvantage [other than difficulty in selling the approach], please do leave a comment.

Developers vs Managers - Part A

One of the pitfalls that we were almost waiting for *not* to happen was developers vs managers confrontation. In our first group we had two developers who were a bit out spoken and their managers were little relucant to leave them for the sessions. The developers seem to have understood the Agile ideas like “the team is the manager, SCRUM Master has no direct authority over the team, estimates can go wrong” a little wrongly. Worse of all, their managers instead of helping them understand these issues - went into a me vs you debate. The result: both the developers have given interviews at a competing firm and the HR department is exercised. The CEO is concerned that managers are getting stressed out because of developers and the developers don’t know why they were taught some things when no one is going to implement it. The classic tussle had started:

1. Project Managers were saying “you don’t need us anymore.”
2. Developers were saying “voa! you don’t know how to manage or don’t understand Agile.”

Our solution centered around talking to all involved separately and on one-to-one basis to understand their view points. We also understood that we need to reorient some aspects of our lessons to emphasize Humility and Teamwork as part of an overall theme. And importantly, we need to let people understand that Agile viewpoints and that “we are not going to solve their problems - they have to figure a way out.” We are there to coach them, help them understand and help them talk - the talking and the walking needs to be done by the team.

Let’s see how this one unfolds.

Explaining SCRUM Basics to Customers - Part I

This week I explained to a customer - what is SCRUM and how to we plan to use it to manage the project [that was currently in progress]. It was the first time someone did this in our organization. However, it was smoother than what I imagined. The customer was more than forth coming and wanted to start with the process right away.

All references to the project and client name have been changed.

Customer says:
what did you have in mind?
Vik says:
We would like to follow SCRUM for Project Management from next week starting with Phase III specifications
Vik says:
you actually have already taken the first step without us asking for it
Vik says:
that is prioritizing the work for us
Customer says:
yes I like the SCRUM model
Vik says:
I think you are familiar with this model – right?
Customer says:
yes
Vik says:
ok – so what we will be doing is giving you a detailed breakdown of list of work to be done for Phase III
Vik says:
please note that this would not cover the work already ongoing on phase II items like labels etc.
Vik says:
which we hope to complete by next weekend
Vik says:
however, we would be starting with work on Monday on Phase III as per priority set by you
Customer says:
ok
Vik says:
we will then track the work on this backlog of work
Vik says:
and visit this once every weekend
Vik says:
or whenever we decide to
Vik says:
and track which items are “done” and which are pending
Vik says:
and then again re-prioritize it on this day
Vik says:
because the priority is not always set and we “might” add more items to the backlog – for instance, the events/ reporting functionality might be higher priority two weeks from now than anything else
Vik says:
does that make sense?
Customer says:
yes it does – I like this model
Vik says:
ok – here are some things which you might be interested to know about”;
Customer says:
ok
Vik says:
1. you can add any item to the backlog at any time
Vik says:
2. however, we will change the priority only when we visit the backlog – this ensures that whatever we take up we complete fully and then move on
Vik says:
3. backlog can have items like “data should be preserved when implementing new functionality”, “the speed should be 1-2 seconds on 56k modem” etc.
Vik says:
4. in rare case if we need to re-prioritize earlier, we can cancel our work and start afresh [however, because we are visiting the backlog once every week – this should not really be the case]
Customer says:
ok
Vik says:
daily status update would be provided to you by team on what they did
Vik says:
also – the detailed task breakdown for the work would be sent to you for each week
Vik says:
I think its important we follow a structured approach because project is now on a critical stage and we need to optimize our growth from scalability, fast turn around times to opportunities and also maintaining a good/ clean code
Customer says:
I totally agree
Customer says:
I think that this is a great approach for V3
Vik says:
Do you have any questions?
Customer says:
not at this time….
Vik says:
ok – if you were to have any questions – please let me know
Vik says:
I am starting a new thread “SCRUM and Project”
Vik says:
in case any one has any questions – you can post them there and I will respond within 24 hours
Customer says:
perfect
Vik says:
however, please note that this calls for a commitment from your side to be available for a weekly chat
Vik says:
this is over and above our other chats we will have
Customer says:
of course – I will definitely make these chats
Vik says:
Thanks Customer. I really enjoyed last 11 months with project and I am sure we would be making a great product in future. At our end, we are committed to help you build a truly world class product.
Customer says:
I am fully aware of that – project is coming along great – we are all very excited about it
Customer says:
Thanks Vik – I look forward to the next level of v3.0 and beyond
Vik says:
Thanks Customer – we are all excited about it as well
Vik says:
Good day ahead
Customer says:
talk to you soon! Thanks Vik

How impressed and excited the customer was evident from the note that he sent us later in the day – “I forgot to ask you guys what day do you think would work the best for us for our weekly meeting?”

What I tried to do was keep this simple and away from jargon. I exposed him to terms like Project Backlog but that was it. There was no mention of Sprints, Sprint Backlog, Burn Down Charts, User Stories, Velocity etc. I think we would need to introduce these terms slowly. It is looking exciting over here.

————————————————————————-
Journey from no-style Project Management to Agile Thinking and Principles
http://agilediary.blogspot.com/