Building Deliverable Software
Reading time: 4 minute(s) - 700 words
Making deliverable software is not easy. The code is one thing but people are the biggest problem. People and their expectations to be precise.
“The client needs it today…”
“They’ve changed there mind…”
“We have a new design…”
“Feature x is more important to complete…”
Anyone involved in software or web development will know those (and more) statements.
They happen in all projects where there is a need for some code to do something.
I’d love to say that projects always run with proper observation of the rules.
Rules around project timelines, sprints and backlogs.
Oh, you can dream. You can mention it in your next stand-up - tomorrow morning, right?
What’s that? You don’t do daily stand-ups?
No, me neither. I’m not a fan of meetings. Including ones where the average answer is: “Same as yesterday…”
There has to be a plan…
I agree, there does have to be a plan. And there does have to be a prioritised backlog. One that is alive and breathing.
That way, you are working on the stuff that matters.
But more than anything else, it’s about getting to a deliverable…
The agile manifesto says this:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Yep, as the years roll by I buy into this one more. It’s the only plan you need.
Will this work move you closer to a deliverable? No, well park it then and do something that will.
What does a deliverable look like?
The clue is: valuable software, You push to get something working as early as possible. Strip away the nice-to-haves. Work for the must-haves.
It might not look like the business. But if it works like the business that’s a result.
It’s valuable because it works.
It works and meets the customer expectation for this stage of the project.
The beast of expectation
If you manage expectation you also manage the development timeline.
There will be people who want it all, today.
Ignore those people.
Your real partners in the project (that includes the customer) are the ones who like to see a deliverable.
Even when it’s early and clunky as hell.
They can see the big picture.
Managing expectation is as important as writing code. Yes, I do mean that.
The backlog (again)
I’ve mentioned this already. But the product backlog is your most important tool.
It’s a prioritised list in its simplest form.
But what an easy win.
Tick something off the top of the backlog and you have an early deliverable.
People (product owners) will be happy.
You’ll be happy because you move on to the next thing. If the backlog changes, it’s fine.
You still win because you are working to the next release.
That’s what it is. A release. Something finished and ready to go. It’s an addictive feeling to know you are not stuck in a rut.
There may be trouble…
What happens when something is hard to do?
The next thing on the backlog is difficult.
Break it up. Reduce the task into small steps and solve each one of them. It might take longer at first.
But solving each little problem will feel like a win.
And you get to a deliverable again. Even if it’s a small increment. Taking a huge bite is great - if you can do it. But stopping is not an option.
A smaller bite = some progress instead of no progress. We are back on a winning streak.
One more thing…
I’ve been creating code for 20+ years. I’ve seen projects dragged over the line by a team that haven’t slept for days.
I’ve seen projects sail over the line with ease - nobody was sure why.
And I’ve seen projects where the focus was always to get to a deliverable. There may have been bumps in the road.
But the deliverable happened - always.
And that works for everyone involved.