Agile: It's Not All Sugar & Spice

Why client education is needed when going Agile.

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.

From Requirements to Production

Reviewing the process which takes place from requirements gathering all the way up to production.

Every small web development agency is unique in some way, this is usually what gives them some kind of competitive advantage. Part of that uniqueness is the process they use to convert what a client wants into reality (e.g. a website). This article discusses that process in a big picture kind way, the main focus is on roles - or who does what.

I've seen a few versions of this process at different companies I've worked at, but they mostly involve the same players each time (e.g. a sales rep, a project manager, etc).

Most small web agencies could say their work is divided into two arenas: small web projects and custom development. Small web projects would be basic websites such a business web presence. A custom software build covers all other scenarios (e.g. where a lot of code is written to account for the client’s unique business rules).

The processes described in this article are most relevant to the small web projects stream, mainly because this kind of work is generally the same thing over and over again (e.g. client: "I would like an about us page, and a contact page...").

The players – before we begin the discussion in earnest, we should establish the roles in the process, or 'who does what'. Job responsibilities often go hand-in-hand with a job title, but not always. So, lets introduce the players:



In the first approach, which I like to call the split-role approach, the process unfolds as follows:

1. BDM sells web solution to client.


2. Business Analyst contacts the client to take-down their requirements (and then hands that over to the Project Manager)


3. The Project Manager organises production resources.

The alternative method is called the dual-role approach, which looks like this:

1. BDM sells web solution to client.


2. BDM gathers requirements from client and hands it over to the Project Manager.


3. PM/BA reviews requirements (and often asks BDM to gather a few more details).


4. PM organises resources and ensures delivery

I should mention that I specifically haven’t represented the iterative nature of development in either diagram (for the sake of simplifying the diagram).

Each approach has certain strengths and weaknesses. The most obvious difference between the two structures is that the dual-role approach combines the jobs of a Business Analyst and PM into one individual. The benefit of this is it cuts out one communication channel. The downside is it can be hard to find an employee with evenly matched business analysis and project management skills.

The dual-role approach also requires that the BDM have business analyst-like abilities, not as refined as a true business Analyst, but pretty savvy none-the-less. The fact that the BDM is capturing basic requirements takes a load off the PM/BA combined role, allowing them to effectively manage more concurrent projects.

Since the BDM is acting as a watered-down Business Analyst, its likely that the Project Manager/Business Analyst will often need to get clarifications on the requirements which have been gathered. For instance, the BDM may write down: "the client wants to put their products online", to which the PM/BA may say "does the client want to sell their products online, or do they just want an online product catalogue?"

The biggest concern for the BDM/BA combined role is that the skills needed to be a good BDM and a good Business Analyst aren't the same. Most BDMs aren't as structured in their thinking (which is needed to gather solid requirements), but then again most BAs don’t have the soft-skills a BDM generally has.

Pricing considerations - since we are dealing with basic website builds here, it is fine for a BDM to provide a client with a ball-park estimate at the initial client meeting. The final pricing does need to be settled by a proper Business Analyst though, they are the only ones that can cost the project with the least amount of risk.

There is also the issue of up-selling and business re-engineering. On the one-hand, a Business Analyst consulting directly with a client may improve the technology solution by making useful suggestions (split-role approach). The flip side would be a BDM is more likely to get a greater budgetary commitment from the client, due to their selling expertise (the dual-role solution).



Personally I prefer the duel-role approach since it reduces the number of communication channels (or 'integration points'). The more communication channels, the greater the risk of losing information or misinterpretations. In addition, small companies generally can't afford to hire specialists (i.e. a specific person for a Business Analyst role, another person for the PM role). I can however appreciate that the split-role approach offers some degree of scalability since there is more division of labour.

Special thanks to members of the Stack Overflow community for their contributions towards this article.

Subscribe to RSS Feed.