Managing Change in a Software Project
Reading time: 3 minute(s) - 500 words
Changes in the development cycle are a good thing. Plans for building software often fail anyway, so change shouldn’t be feared. Here’s why…
Clients don’t know what they want in detail. They know in a broad sense. You’d hope that isn’t the case. But in reality it often is.
So, you start to build (let’s say a web application) and release early.
Then, you start getting change requests. That’s annoying if your mindset is: stick to the plan.
Why not plan in the new work needed and carry on?
How bad is that really?
Not very is the answer.
With one important caveat.
Changes must be managed within agreed parameters
It won’t work for anyone if the changes keep coming without any planning. There has to be set tolerances so the business case for all parties stays intact.
Build something that works
Your start by building something that works.
That way, everyone (the developers AND the customer) can see what the app will do and what else it could do.
You keep going with this phase of building something that works. It won’t be finished and it won’t look pretty. But you are still making working software.
At each review, it becomes easy to make proposed changes because you’re not locked in to a rigid plan.
Agree on the good parts
As new features are added, the unchanged ones are marked as done. They’re signed off as such.
Refactoring of those parts can happen to make them right. Polished, efficient code. While new stuff is still being thrown in.
The good parts stay good. The new stuff works but is under review as before.
Here come the changes
It might be that changes are needed for finished parts. That’s fine too. Because the mission is: to make working software matching the clients requirements.
And remember, the client may be internal. Your stakeholders are your client/customer. But the guidelines are the same.
Late changes happen because requirements get identified late in the project. Refinements are brainstormed and added to the backlog.
There’ll be new use cases or user stories. Perhaps both.
The development team manages because they’re focused on making the best product they can. They’re not following a rigid plan.
Does this project ever get finished?
You know what? Maybe not. And that doesn’t matter. You still get working software. You still get software that is efficient. Because everyone is focused on that.
But new ideas and features are welcomed. Perpetual beta is NOT a bad thing. It allows the app to meet requirements - even as those requirements change.
The bottom line?
Don’t fear perpetual beta, as long as there is working software.
One more thing…
I’ve said it but it is worth repeating:
“Working software is the primary measure of success”
It says so in the Agile Manifesto. Embracing changes (even late ones) means the client gets the software they need. And that matches the measure of success too.