The desired benefits of agile development are many:

• The customers are happier and more willing to buy.
• The lead time from idea to delivery is shorter.
• The employees are more motivated and more productive.

Sounds good, doesn't it? In practice, certain behaviors stand in the way of the benefits. As a scrum master and agile coach, I see the same anti-patterns in many companies over and over again.

Today's anti-pattern is about project budgeting and contracts.

Fixing the scope - not a good idea

In many companies, the scope of delivery must be fixed first. Then someone estimates the effort and calculates the necessary budget. Then there is a go or no-go decision for the project.

It is similar for many customer supplier relationships. First, a contract must be set up that describes exactly what will be delivered. Otherwise there is no order.

How else could it be? How else can you, as a customer, be sure what will come out in the end?

As an agilist, here's my answer. As a customer, you can't know the exact end result in advance anyway. Software development is full of surprises. The requirements of today are history tomorrow.

It's important to recognize the tension between predictability and changeability. You can't have both: perfect predictability of the end result at the beginning and maximum consideration of change requests later.

What you can do instead

At the beginning of agile development, it is sufficient for stakeholders to agree on a product vision. And maybe a rough roadmap. Funding can be done incrementally, sprint by sprint.

But what if this is not possible in your company? What if the stakeholders don't want to give up the illusion of safety that comes from clarifying requirements early?

Well. It's a waste of time to specify details of requirements that will change later. So what to do?

You can agree on user stories in advance. That makes sense. But don't define the acceptance criteria! Clarification of details is postponed to development, shortly before implementation.

The advantage: you can react to lessons learned from development. And new customer needs.

Change management done right

Either at the beginning of a project or during contract negotiation, stakeholders should agree on the mode of cooperation and the handling of changes later.

It is important to follow a few principles.

If there are changes, a change management process that evaluates each change individually is NOT enough. Instead, a change should be related to other changes.

For each change that is implemented, either

• take another requirement out of scope, or
• increase the duration of the project.

During development, individual elements can therefore be replaced by elements that are equivalent in terms of development effort. Scrum supports this with the Product Backlog: by pulling a backlog item up, the other elements automatically have less urgency.

If you want to know more about agile contract design, I recommend have a look at Money for Nothing and Your Change for Free.

To get the basics of agile software development right, visit my online course..