The desired benefits of agile development are many. Customers are happier and more willing to buy. Lead time from idea to delivery is shorter. 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 decided on first. Then someone estimates the effort and calculates the necessary budget. Finally, 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. Customers can't possibly know the exact end result in advance. 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 important 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 you 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. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.