Agile Contracts

622

Agile software development contracting is distinct from traditional project contracting. Using traditional contracts for an agile development project can jeopardise the project execution and the company’s potential benefits. This article throws light on Agile Contracts.

In our clients’ eyes, we aren’t making ourselves agile. They want to remain the same. We run the risk of trying to push our own projects and drives on them if we do so. And a plethora of more options!

We could try to have these dialogues with our customers, but how are we going to handle their contracts? Business arrangements? policies regarding pricing The engagement model and other things.

A contract is a formal agreement in writing.

1. A contract describes the partnership between two parties and includes the goals of the project, as well as the values and thinking of the parties involved.
2. A contract replaces lack of confidence. Trust between client and supplier reduces paperwork.
3. Contracting with an Agile partner works best when both parties adhere to Agile values and principles.
4. Continuous procurement process that assures suppliers – and buyers – comply to stated contractual duties, as well as discussing future adjustments.

People's behaviour is influenced by the contract's provisions.

Why a Contract (or what is in it)?

1. People change, therefore the decision-makers you interact with now may not be the same in the future. Power and influence fluctuate even among the organization’s leaders. A contract provides continuity as organisations evolve. (legitimate)
2. To improve risk management and knowledge. (knowledge of scope, budget, timeframes, quality, vision, and direction) (legitimate)
3. Management of risk occurs when decisions are made with insufficient knowledge. You guess, decide, spend money, and hope for the best. The facts will emerge later (validation phase). (Can be better addressed)
4. A contract manages some but not all risks. BAD COOPERATION WILL NOT BE COMPENSATED BY A GOOD CONTRACT.

What are the some of the risks?

1. Is there anything useful in the delivery?

What if you didn’t have to wait the whole project to get your delivery? And you get frequent tiny deliveries to test usefulness.

2. Time and Budget Risk: Will it be delivered on time and on budget?

Among other things, the cost is determined by the number of individuals participating and the project’s duration. A set pricing is easy to achieve if you limit the project time but leave the scope free.

3. Do I get all I asked for?

Getting everything would have been ideal, but which is more necessary, ‘things for next week’ or ‘things for tonight’? Which choice gives you more options?

Agile Risk Handling

1. In Agile, you manage risk by committing to a course of action for a limited time. You commit during the time-box (PI/Sprint). After the time-box, you can change direction. (Budget)
2. Failure with grace If you can’t complete everything, deliver less but on schedule and on budget for the sprint/PI. Deliver business-critical features with quality. (Risks)

3. Time, money, and scope are traditional project success indicators. Affordably on time? Did it include all features? The scope is perhaps the least vital.(Scope, Time)

It's usually preferable to be early with the most significant features than late with all.

4. Buyers usually mean fixed-time, fixed-scope, and fixed-price projects. This is problematic because poor quality can have a big impact on the entire cost or even the success or failure of a software product. (Q&B Risk)
5. In terms of total cost of ownership, prioritising quantity over quality is a costly choice. (Delivery/Budget)
6. A contract that prioritises scope delivery over technical excellence and internal quality may result in a product with high “technical debt” and high maintenance costs. (Q&B Risk)

 

BID (RFP/RFI/RFQ) And Estimations

• Current sourcing methodology, using RFPs or RFQs, is effective for projects with several stages, like the runway, but will fail when there is no certainty before a project is started.
• Truth be told, estimates are all just lies. It’s important to appear you know what you want and that you know how much time and money it will take to deliver it, if you want to land a contract.
• Estimates are, by definition, estimates. Your expectations will not be met. Predicting the effort required is a difficult problem to solve.
• Fixed-price bidding usually results in the supplier coming in at the top of their estimates, thus mitigating their risk, or the supplier merely commits to supplying a part of the necessary functionality. The suppliers’ major techniques for reducing time and budget risk are known as buffers.

They will be unable to obtain the business until they play the game. It all begins with a lie.

How will the provider focus on technical excellence and internal quality (technical debts)?

Imagining an Agile Contract

1. An agile team usually works from a product backlog and a goal. That is the product’s intended impact. The vision describes the product in brief (and often what it is not)
2. The product backlog describes the product’s capabilities.
3. The commercial contract can refer to the Sprint/PI contract or Managed investment. By the third version, the commercial contract can be reduced to one page Time & Materials agreement, with a cost ceiling for the quarter.

From a contractual perspective, any fixed scope contract is either non-agile or faux agile.

4. Fixing scope is simple and cheap. To save money, add another sprint. If not, don’t.

The greatest method to know you can release on time is to release two weeks ahead of time. And two weeks prior. 

Which projects suit Agile Contract?

An engineering project. How can you know if your project is an engineering project? Some tests:

Good Read: Value the Agile Mindset Over Methodology

Lastly

A non-agile or phoney agile approach will likely result in a lengthy and costly “change request process” and a product that “misses its target market.”

If the contract limits the opportunity to adopt improvements (review and retrospective), it also limits “Team Performance” and eventually affects the team’s motivation and everyone else involved in the transformation effort.

We (our needs, society, customers, technology, business dynamics, etc.) are undergoing rapid change. “Continuous Customer Collaboration” is the only way to survive and prosper.