Mastering Agile Development for Freelance Web Developers
There’s a chasm between working for companies who are experienced in writing software, and building small projects for local clients. I don’t think the gap is due to project complexity, scope, or budget; It’s due to your clients not understanding your process.
Think about it this way, writing software is one of the few production methods that’s still done entirely by hand. Your average client is used to purchasing cars, houses, or cups of tea, and hasn’t a clue about why you’re sending proposals with ranges and ambiguity. We have more in common with novel authors than we do with automobile manufacturers.
So you explain how you came up with the numbers behind your proposal. But be warned, your client is going to always remember that price tag you estimated, and they’re going to be pissed when you charge them more after they increase your workload.
If you want to have a project that doesn’t go up in flames, you need to educate. Agile, at least to me, can be reduced to a simple proposition: writing software is exploration. Like a fractal pattern, from far off it looks a lot less detailed and complex than it is up close. Your clients will change their band, ditch and repeat, and a lot of other things that – unless you’re careful – could seriously jeopardize your relationship with them.
So how do you educate?
The first step is to get rid of absolutes. You have no idea how long X will take to build, and stop pretending you do. Next, let your client know that no project looks the same on delivery as it does during planning. Lastly, you need to present yourself as a consultant. Work within the boundaries you’re given – time and budget – and work with your client to see exactly what they can get given these constraints. Don’t pigeon hole yourself into a situation you’re uncomfortable with.
Clearly communicate the uncertainty in the work you’re doing. It’s almost impossible for you to be on the same page as your client before you dive into it, and it’s certain that your client doesn’t truly know exactly what they need built. Things will change, and the change works best when both parties embrace it and have a process in place that accommodates change.