There is a big internal battle raging within software development today; it's between satisfying the needs of the client and safe-guarding against disaster. This shouldn't inspire a paranoid outlook, but rather invite caution and awareness.
The old way of making software, like what I was taught back at college, was to write everything down in a spec and treat that document like the stone tablets Moses brought back from the mountain. This 'big spec' approach produced long boring documents no one wanted to read, let alone write. The spec was great for developers because it protected them, at any point of deviation programmers could tell a client "if it's not in the spec, you can't have it - tough luck."
But as you can see, that isn't exactly good customer service.
Eventually Agile burst onto the scene, with its shinny snake-skin boots and promise of a better tomorrow. The method's greatest strength was its total appreciation and encouragement of the cyclic nature of software development. It was all about 'small chunking' things, favoring less yet more stable features, and demonstrating continual momentum. But this article isn't a treatise on Agile; there are plenty of books out there on that. Instead, this article focuses on the need for better education in an effort to improve a client's 'Agile experience.'
One of the biggest things Agile did was put power back in the client's hands by turning the process into a cyclical endeavor. Instead of writing up a huge spec, and then employing the 'freight train' approach to coding where there's no stopping to take account of new information, little circles of development took place (i.e. sprints).
And here lies the first potential misconception; that Agile is about 'winging it' because there's less documentation. Nothing could be further from the truth. If you gathered together all the email communiqués flying back and forth between developer and client, you'd probably find there is quite a lot of documentation. Feeding, for want of a better word, a client small chunks of information is far more digestible. In practice, this could be as simple as sending an email containing a single screenshot and asking the client "how does this look, do you need me to change anything?"
But, as with any system, there are downsides. Agile solves some problems, but introduces others. And the problems I have encountered are largely due to a lack of education. Although Agile is far more responsive to changes and gets the ball rolling sooner, it has the drawback of requiring the client to have a deeper understanding of SDLC. With waterfall model, clients didn't need to know as much.
You still get problems with 'scope creep' in Agile, mainly because the client doesn't understand how it works. And why should they? They're not programmers. Some people will take it on faith that 'this is the way it's done', and others will require an explanation. This explanation will obviously eat-up project time in the form of consultancy, and that's where the problem lies. The temptation will be to skip this investment in education (and the client is unlikely to ask either).
You may encounter a situation where a client decides to willfully disregard established protocol (it doesn't happen often, but it can happen). Because the client isn't directly part of your team, your ability to get them back on board may be limited. For the sake of keeping the piece, you may begrudgingly decide to do a substantial amount of work for free, even though your contract says you are in the right. This may be a bitter (and costly) pill to swallow, but you either believe the customer is always right, or you don't.
Mid-project is not a good time to air your grievances, in fact, no time is a good time. Your turn will come at the end of the project where you decide if you wish to keep the client or not. Or you may decide to hike-up their hourly rate to account for the increased risks involved in working with them.
The drive for better education is all about bringing the client into your world (i.e. software development). It's simply the logical counter-part of being brought into their world (i.e. their business domain). For the project to succeed, developers must have a more than passing understanding of the client's business. So it only makes sense that the reverse also be true. This has traditionally not been an expectation in the client-to-supplier relationship, but hey, things change.
Subscribe to RSS Feed.
