Agile Contract Types

What are Agile Contract Types?

When it comes to agile methodology, both the vendor and the customer have to come for an agreed agile contract type prior to the execution of the project. Since agile is defined to be embracing changes, it’s difficult to establish a contract. Both parties are supposed to cooperate with each other in order to deliver value adding features throughout the entire project life-cycle. (The relationship between the customer and the vendor in agile methodology has been defined and stated under ‘Agile Manifesto Principles‘ and ‘Agile Manifesto Values‘) There are few agile contract types defined to be used based on few factors such as the relationship strength between the customer and vendor, etc…

Even though embracing changes has made it difficult for both parties to sign an agreement, there are few contract types that still both parties can agree upon prior to the project execution.

Fixed price, Fixed scope (Fixed time is also preferred)

Under this contract, an agreed budget with a fixed scope is provided (Just like in waterfall). By using agile techniques, project efficiency can be enhanced in order to gain maximum benefits out of the agreed price. This contract is good to use when requirements are stable and the relationship between the customer and the vendor is not stable (Not trusting each other).

Fixed price, Fixed scope (Fixed time is also preferred, but scope can be altered by collaborating with the customer)

The project team works closely with the customer from the beginning to identify the project requirements and priorities. Once the project is started, the project management team has to work on a prioritized list and at the end of a delivery, both parties can discuss whether to change the project direction based on the user needs.

Time and Material

According to this contract, customer has to pay for the work being done. This method / type works better when requirements are not stable / volatile. This is the simplest contract to be signed off if both parties trust each other.

Not To Exceed with Fixed Fee (NTE/FF)

Here, the vendor team is promised with a guaranteed profit margin. Both parties protect each other with the speed of project work being executed (Faster or Slower) and work on unexpected events to drive the project towards success.

Fixed price per function / story point

Initially both parties must agree on the unit of delivery (story points / functions / function points). A fixed price per unit is agreed and a certified functional point auditor is selected and advised to observe the number of units delivered at the end of the project. The customer has the freedom to change the requirement throughout the project and the vendor is encouraged to work efficiently.




Continue Reading

Agile Manifesto Principles

Agile Manifesto Principles

Apart from the values stated under Agile manifesto, there are 12 principles identified to be explained under the same agile manifesto concept. Those 12 Agile Manifesto Principles are as follows;

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

This principle explains that the project team’s primary focus should be to satisfy the customer as early as possible by producing a valuable product using continuous delivery. (Not documents or project plans)

Welcome changing requirements even late in development. Agile processes harness change for the customer’s competitive advantage

It’s understood that the customer’s market is dynamic, hence requirements change is always dynamic based on the competition. There cannot be any integrated change control system to be followed under agile methodologies.

Deliver working software frequently from a couple of weeks to a couple of months, with a preference to other shorter timescale

It’s recommended to receive an early feedback without continuously working on the project and ultimately producing a wrong product. The project team has to make changes where necessary.

Business people and developers must work together daily throughout the project

Both the customer and the team must share the same vision and goal. Both parties need to have face to face conversations more frequently. The product owner must work closely with the project team and advise them accordingly. Both parties can negotiate on requirements and produce frequent demos of the product.

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done

It’s always advised not to tell the team how to build the product, but what to build. The team should be empowered, recognized and delegated. The team has to facilitate team work and collaboration. “Knowledge worker” cannot be micro managed.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

The ‘face-to-face’ method has been identified as the best communication method so far. Written documents are slow and maybe producing wrong info: / details on the project.

Working software is the primary focus of progress

The team should add value to the customer. Therefore, it can be achieved only by producing a working product / software. The team has to switch from plan driven to value driven. Other activities such as planning and documentation can be considered supporting activities.

Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely

The team is advised to follow a good work life balance, no long hours working. Short iterations can be repeated to produce the final product. Effort needs to be distributed more consistently.

Continuous attention to technical excellence and good design enhances agility

The team should focus and pay more attention towards balancing the high value and flexible design. Processes such as refactoring, automated testing, continuous integration can lead the project towards technical excellence.

Simplicity – The art of maximizing the amount of work not done is essential

It’s recommended to build what’s only necessary for today. Team should not build anything based on their own assumptions. Only the simplest thing that could possibly function according to the client’s requirement needs to be built.

The best architectures, requirement and designs emerge from self-organizing teams

Team must be cross functional, self organized and self managed. Team has to decide how to do and who should do what. Everyone has to have a sense of ownership of the product and should increase the commitment towards work.

At regular intervals, the team reflects on how to become more effective, then tunes and adjust its behavior accordingly

Team should continuously improve their processes in order to be more efficient and effective. They need to have retrospective sessions to see what needs to be stopped, what needs to be started and what should be continued.

Continue Reading

Agile Manifesto Values

Agile Manifesto Values

The Agile Manifesto Values define how the values behind Agile framework function to lead projects towards their success. According to the defined manifesto, a group of 17 thought leaders including Alistair Cockburn, Kent Beck, Jon Kern have identified 4 values . The ‘Values of Agile Manifesto’ is stated as follows:

“We are uncovering better ways of developing products by doing it and helping others do it. Through this work we have come to value;”

Agile Manifesto - Values
Agile Manifesto – Values

Individual and Interactions over Processes and Tools

People are considered the most important factor. Team is driven to focus on individual and interactions. This value promotes the self management and shared ownership of the project.

Working Products over Comprehensive Documentation

This value focus on delivering a working product / software. Documentation is necessary, but without a working product, documentation won’t do any good. Team should not let the documentation process to distract themselves from producing a working product.

Customer Collaboration over Contract Negotiations

It’s normal that the business requirements change from time to time, hence putting everything under a contract at the beginning itself will not be practical. Both parties (Team and the Customer) must be flexible when it comes to embracing change to the product. Team should work closely with the customer to achieve a shared vision and goal. Therefore, both parties need to build trust among themselves and proceed with flexible contracts.

Responding to Change over Following a Plan

Requirements change frequently based on the client’s needs. Therefore, coming up with a concrete plan from the start of the project will not be effective. It’s recommended to initiate the project with a high level plan. Next, with more info: and knowledge related to the product being gained from time to time, improve the feature list to-do and execute the project based on the priority. In order to succeed with this, every team member is advised to participate in planning the product list.

Continue Reading

Agile Project Management

What is Agile Project Management

The term ‘agile’ comes from the phrase ‘Agility’ which defines the ‘ability to quickly adjust and respond to changing business needs’. Managing projects using the agile methodologies is knows as the Agile Project Management. Agile is a mix of both iterative as well as incremental development.

Agile = Iterative + Incremental


The project life cycle is composed of several iterations in order. Each iteration is considered a mini project and after several iterations, a release happens which builds a stable, tested, partially completed system


System grows partially in each iteration adding new features to the project, hence the system is built incrementally.

In order to follow basic approach of agile, there are 4 general steps to follow.

  1. Make a list of features (Product Backlog) that need to be included
  2. Prioritize the list according to the value and the size of the feature
  3. Build the features from top to bottom until the fixed time is run out
  4. Repeat the process until the entire list is completed

Sometimes certain organizations feel that adapting to 100% agile project management is risky, hence they come up with a hybrid model that combines a part of waterfall methodology as well. This is a smart move since it doesn’t over-compromise both methodologies.

Agile Hybrid Model
Agile Hybrid Model

Agile projects are executed in several stages which include sprintsĀ  and releases. (Refer below image for further details)

Agile Project Stages
Agile Project Stages

Agile Paradigm Shift

Agile methods are ready to welcome / embrace changes to the project (unlike waterfall methodology). Hence, instead of making the ‘Requirements’ a constraint, it works with fixed cost and time and allows the team to build as much as possible during the period of fixed time. And with few iterations and releases, the entire project is built.

Waterfall Methodology Agile Methodology
Requirement is a constraint Schedule and Cost are constraints
Cost and Schedule vary Requirements can vary
Plan Driven Value Driven
Continue Reading