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..
Top comments (9)
I think that the single biggest problem in this area is trust. If there is mutual trust between the party that is making the software and the party that is paying for it, that goes a long way. Otherwise, any kind of change will be treated with suspicion. One thing that agile approaches try to do is to bring these groups together into cross functional teams, so that the customers are involved in the day to day work. That helps a lot in building the trust that's needed for this approach to work effectively...
You're absolutely right. Trust is a major issue. That's why close collaboration and reliable delivery are so important.
Yes, though I think it's possible to fix the requirements, but then you have to live with a potentially unlimited timeline. Thus, it's wiser to fix timelines and have loose user stories instead.
I talk briefly about this in my upcoming book: edaqa.com/on_programming/ Though I image it's a topic that will need a book all on its own -- just to cover the idea! :)
You’re right. But the common way to plan projects, that I refer to as an anti-pattern, suggests fixed scope AND fixed project end date. I actually experienced a project where money wasn’t a thing once - there, I could have applied what you said. :-)
If an electrician or plumber or any engineer starts talking to you this way you will never hire him.
So you wouldn’t pay a plumber in your home if (s)he didn’t predict the end result and budget, is that what you’ trying to say?
If yes, I fully agree. The reason why this anti-pattern exists is that something complex (software development) is modeled after something complicated or simple (like plumbing).
In case you‘re open to learning about that, check out the Cynefin model.
Your analogy highlights something else: software delivery - like plumbing- is often seen merely as an investment, while in today’s digital age, return on investment should be considered.
Finally, there are cars and fighter planes built with Scrum. So it’s possible to apply agile practices to engineering as well.
My point was - you should be able to estimate efforts. And customer should be aware that any scope change basically returns you back to the beginning of the entire process - more or less. I am fully aware, that one can't predict everything and like a plumber who first needs to break the wall to see where exactly the pipe is broken, and how bad the problem is, then tell you what you have to do next and what your options are. This is the agile part precisely, but nevertheless we are professionals and we should be able to estimate how long it will take to do something.
I've dealt with various contractors for things like home renovations, and the original estimates for time and cost are basically worthless in that case.
For something simple, like replacing a sink or fixing a leak, they'll generally stick with the original estimate.
Just like software development, isn't it? Simple things are easy to estimate and do. When complexity increases - everyone fails to estimate correctly. However if a contractor offers you to replace your floor for $10000 and then suddenly it turns out you have to pay extra $25000 because your house on the southern side of the hill and it's a leap year and it turns out it's a full moon the week when they will finish and they charge extra for this or you will have to wait another 3 months, then you will be really pissed.