They don’t know what they want!

Developing software can be frustrating. In a recent discussion with a junior developer she said, that it’s not easy to develop software. In long hours of hard work the result is built as previously discussed and it works. But the customer says, that’s good, but not exactly what we need.

I remember that feeling, It’s disappointing. Short before the deadline the customer want’s something different. Often huge changes to the codebase are necessary to meet the new requirements. The codebase you were so proud of before starts to rot and more and more bugs sneak into the code.

Why haven’t they said upfront what they really want?

Maybe they said what want but you didn’t understand it well enough. Or maybe they just learned what they really need after seeing your product the first time. Many problems are so complex, that’s not easy to plan and communicate everything upfront. And also, life goes on – markets and requirements change.

Your cannot change the facts above. As hard as you try and the more you plan upfront, you’ll need more time for a solution and it will have the same problems.

Try to start small and involve your customers as early as possible. Try to provide value as soon as possible. Start with a small subset of all the features that the customer wants. Show him the result, and in many cases they are happy to have an incomplete solution early than waiting a long time to get a (maybe) complete one.

This way, by involving your customer, you’ll get early feedback. Early changes are easier and cheaper. You’ll also discuss the details of the feature that should be developed next and the customer can re-prioritise continuously. There will by features the customer said “we’ll need this later, I’m sure”, but then skipped over and over again – or dropped.

The customer want’s working software, as soon as possible. It’s our job to deliver it. This requires planning, effective communication and high-quality (tested) code. Design for change, but build only what’s necessary.

You don’t have to use scrum to be agile, learn about the agile principles & patterns. Change your perspective on the current development process.

Have a look at the “Principles of the agile manifesto“.

“Agile” software development is not the solution for all your problems. But the insights you’ll gain will lead you to a better process. Don’t be the slave of a process, use a continuously reviewed process as a tool.