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.

Making Customers Part of the Development Process

Helping customers understand and get involved with their software project.

The importance of talking to customers about how you will be building their software shouldn’t be underestimated. If you wait until the project is under way to begin managing a customer’s expectations, you'll find it’s too late; expectations have already been set (not necessarily in a good way either).

You can generally assume that in a client's mind, the methodology you use is unimportant minutiae, they are not interested in the nuts and bolts of the process. They only care that the project gets done. This is not to say that the SDLC approach used is trivial; some clients are more suited to an Agile approach whilst others will be happier with classic waterfall. In the case of B2B, where a client may have a technical stake-holder directly involved with the project, keep in mind that there’s no point being ‘agile’ if your client doesn't buy into this too.

Whether developers use Agile or waterfall model is beside the point from a client’s perspective, these are purely internal processes. The only time a client needs to know about the process is at their interaction points. This is like encapsulation in object oriented programming; all a coder needs to know is what the interface looks like and how to interact with it. The inner workings of the function are not his concern.

The key to involving clients with the development process is to only discuss processes which involve them directly. Clients need to know ahead of time what they're getting into and what to expect. Surprising a client with new information half-way through a project often sounds like an excuse. Some development houses use a 'client education pack'. I believe this is a good idea as long as a project manager walks the client through it either in person or over the phone. Assuming a client will want to read a 20 page process manual you send them is just wishful thinking. The client needs to be part of the development process at any point where their input is required. Examples of this would be: meeting with you to describe what the software is meant to do, providing content for their website, approvals (e.g. design sign-off, UAT, etc).

Arguably the most important point to bring up with a client is the effect of adding features to a project already under way (i.e. ‘scope creep’). There's more to this than just saying "if its not in the spec, it will cost extra". There are implications relating to delivery date and more subtle dangers like new features breaking previously working ones. You may have techniques for dealing with these issues such as incorporating a change request budget into the fee proposal or requiring that non-critical features be implemented after initial release.

Another important topic is the interconnected nature of features. Functional dependencies aren’t just confined to the realm of coding, they may extend to tasks requiring a client’s involvement. For instance; a client may not know that credit card transactions can’t be processed on their ecommerce-enabled website until they get an Internet Merchant Account and sign-up with a credit card clearing service.

It’s unrealistic to think business interactions will go smoothly 100% of the time with all customers. That would be like thinking you can please everyone; you can't. This brings up the subject of choosing your clients, or even dropping troublesome ones. Dropping a client would seem counter-intuitive, after all, a business is there to make money, so turning away a paying customer seems kind of crazy.

The reality is that on occasion you will encounter clients who are inflexible or uncompromising. The author Stephen Covey perceptively described the outcomes of interpersonal conflict in his famous book Seven Habits of Highly Effective People. They generally follow this structure: win/win, win/lose, or no deal. In terms of conflict with a client, the win/lose situation would be: 1) developer insists on following their internal process but angers the client (win/lose), 2) developer compromises their process to keep the client happy, but delivers a shoddy product (lose/win), 3) the developer drops the client (no deal). Ideally you would go for win/win situations as much as possible, where both parties get what they want without taking away from the other. A win/win solution is nearly always possible if both parties sincerely commit to working on a solution until an amicable outcome is achieved.

It's important to keep the big picture in mind, if it’s only a trivial point, it’s best to let it slide. For example; a client may insist on red flashing text on their homepage. In such a case all that needs to be said is: "this is a usability concern, I can still change it for you if you like but it will hurt the quality of your website."



At the end of the day it's not the responsibility of the client to understand software development, or anything else for that matter. Their primary responsibility is ensuring that enough budget is available to bring the product to fruition. The technology supplier’s part is to deliver on what’s been promised. Using the hottest development methodology doesn't mean anything if you’re losing business or ruffling your client's feathers. Software development is a service industry; clients aren't concerned with how teams or projects are managed to an intricate level, they care about what they've paid for: results.

Subscribe to RSS Feed.

The Scourge of Unnecessary Meetings

Tactics for reducing time spent in unnecessary meetings.

As a project manager that used to be a programmer, I can recall how much I loathed sitting in meetings. My train of thought was commonly along these lines; “why am I in this meeting talking about the project when I could be out there coding it?” Because of this, I do my best not to subject programmers to meetings unless it's absolutely necessary. Obviously not all managers come from a technical background, so this empathic understanding may not be present.

Ad-hoc meetings are a growing trend, but its not always convenient for three or more people to stand around discussing the details of multiple projects in an open-plan environment. When it’s realized that an impromptu discussion is probably disrupting other people around you, the common suggestion is “lets take this to the boardroom”. Now you have an ad-hoc meeting which has become the real thing, a meeting which can potentially turn into a lengthy discussion.

This brings us to the topic of written agendas, some swear by them, but are they in keeping with the spirit of Agile? Having someone write up an agenda is added bureaucracy. For short meetings at least, I believe agendas can be substituted with presence of mind and self-discipline. You need to be able to say two things in a meeting without being viewed as negative; “we’re getting off track here” and “we need to move on to the next item”.

Ideally, a project manager should do everything they can to shield programmers from meetings. If operational management is going directly to programmers for project status updates, then the project manager isn’t being allowed to do their job properly. It is not unreasonable to expect a project manager to know exactly how a project is progressing at any given point in time.

How does a project manager keep abreast of project status? Simple, by maintaining a project schedule which programmers go into 1-2 times per week and update their particular sections (e.g. when Jane finishes the validation for the sign-up form, she marks the task as 100% complete). Most other situations can be handled as one-on-one meetings, by email, or via MSN.

The only time all programmers need to be in one room at the same time is when they all have to talk to each other. Senior programmers must bare an additional burden; they are commonly needed in meetings to provide technical expertise.

Development team meetings are an exception; by this I mean meetings with nothing but programmers in them. These meetings are rarely superfluous, programmers will be itching to get back to their computers and continue with their work so they wont waste time on unnecessary matters.

I hear you saying “but if you keep programmers out of meetings, they wont interact with other staff and wont know what’s happening in other departments”. You can’t cajole a team to ‘jell’ by putting it into a contrived environment such as a meeting, which is an inherently formal situation anyway.

You’re more likely to build a sense of internal community by organizing events which are obviously social gatherings (e.g. everyone leaves the office at 4.30pm to go for pizza and bowling). Another way is to provide a pleasantly furnished communal eating area where people can sit and chat during lunch time.

I have seen it suggested that coders answer project status queries by saying something like; “it’s in the bug log”, or “it’s on the wiki”, or “I sent you an email about that”. Even if you assume a manager understood the reasoning behind such a statement, it’s still mildly rude at best and politically insensitive. Perhaps a better version would be “I’m happy to meet with you to discuss it, but it is in the bug log. And to be honest, I would much rather be coding so we can delivered sooner”. Would such a statement work? Who knows, but at least it wouldn’t come across as being negative.

Using MSN as a communication tool is a topic of potentially heated debate. Some companies ban it outright, others embrace it and reap the benefits. I have been at one company where everyone had it on their machines and it worked-out just fine.

Admittedly, sending a message like “can I talk to you when you’re free?” to a person sitting three feet away does feel kind of weird. However, walking over and interrupting them midway through a task is likely to break their train of thought or disturb others sitting near by. There is a degree of ‘knowing what a person likes’ here, if you know a person prefers emails, send them emails, if a person prefers face-to-face discussions, so be it, accommodate them.

At the risk of being facetious, I would say programmers love MSN. This is because it offers a degree of control. An instant message can be left for a few minutes without being answered and doesn’t break concentration the same way verbal interruptions do. I’d say MSN is more suited to specific questions like “will the file upload feature be ready today?” rather then vague queries like “how’s the project going?”

MSN is also great for giving simple instructions like “a friendly reminder Tom, I need you to go into the project schedule today and update your areas” or “the client has logged a few bugs, I’ve assigned them to you, go get them when you’re ready.”

The main danger managers see with allowing programmers to have MSN installed on their computer is that they will talk to their friends; and they will, but sometimes you have to take the good with the bad. Personally, I fritter away maybe 20 minutes per day talking to friends on MSN (e.g. “did you go for a ride on the weekend?”, etc). The problem is when the amount of time spent on MSN becomes inordinate (e.g. 2 hours plus), but this is a matter of self-discipline and only occasionally affects some programmers.

Now we come to one of the most disturbing causes of unnecessary meetings, ones which have been called for the sole purpose of stroking a manager’s ego (nb. this may be on a subconscious level). Tom DeMarco in Peopleware calls these 'status meetings'; not because they are about getting the latest status on a project, but because they are about affirming the bosses 'bossness' status within the organisation. There may be little that can be done about this situation, after all, they are the boss right?

I have seen one company where the managing director would have weekly meetings which went for an hour. During each meeting, he mostly talked at people. Programmers said maybe four or five words in total during the meeting, this was a good indicator they didn’t need to be there.



The bottom line is meetings are here to stay, including the unnecessary ones. This is simply a product of a corporate environment, managers are social beasts who like to talk, programmers are technical beings who like to code.

I have seen programmers suggest other approaches for alleviating the blight of unnecessary meetings. For example; require that an agenda exist before accepting the meeting request, insist off-topic items be discussed at another time, keep a log of time spent in meetings to use as ‘evidence against your boss’ when projects slip, etc. All idealistic and pragmatic, but unfortunately whilst the balance of power remains with the managers, the tilt will remain towards verbal communication.

Sign-off Agreements

Getting closure on a project by using a sign-off document

A Sign-off Agreement is simply a document both client and technology supplier sign at the end of a project. In essence, it signifies that a client is happy with the work they have paid for.

You could say the Sign-off Agreement officially marks the end-point of a project, generally trailing behind UAT (also called System Acceptance). Could you close a project without a Sign-off Agreement? Of course, you may be thinking this process is overly bureaucratic, and that may be true for certain situations.

So, what's the point of the Sign-off Agreement? One reason behind it is to give everyone involved in the project a sense of closure. I would say this idea of closure is a good thing, for one it gives the development team a feeling of achievement. Another important aspect is it sets up a boundary relating to version control (i.e. version 1 is done). The concept of versions for web software is somewhat meaningless because of the ease with which updates can be delivered. However artificial, versions can be good for creating dividing lines between a delivered software package, and its next batch of features.

Probably the best answer on whether you should use a Sign-off Agreement on your project is 'maybe'. It comes down to a few key factors; the type of project you have, the kind of client you are working with, and the situation. For instance, if you are dealing with a government body then a certain degree of governance and process is to be expected. As often as possible, do try and use a Sign-off Agreement, but if you are in a situation where you need to concentrate more pressing tasks, then this process is a good candidate for culling.

An important aspect of the Sign-off Agreement is to make a statement about your Software Warranty. This is where you say how long you will be fixing bugs for free, and also what your definition of a bug is. Another way to think of this is as a rudimentary service level agreement (but without any commitments on turn-around time). Failing to discuss the idea of Software Warranty with your client leaves things open to interpretation and can setup the wrong expectations (e.g. a client may just assume you will be fixing bugs forever). How many months should you offer a warranty for? I don't know, that is really up to you. I have seen 3 months, 6 months, but I also know someone who basically fixes bugs for free no matter how long ago the software was delivered.



I like to keep the Sign-off Agreement to one page since I believe people have better things to do with their time then read long documents. I start with my Document Purpose section so someone picking up the sheet of paper can understand what it is about within a few seconds. The format of Sign-off Agreement I use is not designed to be water-tight from a legal perspective, that is not its purpose.

Towards the start of the document, I have a block called Agreement Parties, this just makes it clear who the client is and who the technology supplier is. The statement about the Software Warranty follows soon after.

The bulk of the document is the Terms section. The main point here is to say that your company has fulfilled all its contractual obligations and that the client is happy with what you have produced for them.

Something you may wish to discuss in the document is a maintenance rate for feature additions post-launch (also putting a time limitation on this quoted rate). I will probably be moving away from this style of agreement in favour of more flexible system involving Maintenance Blocks, but this is a discussion for future, after I have had a chance to road test the concept.



The last part of the document is an area for one of your company representatives to sign and date, and an area for the client to do the same (it is called a sign-off agreement after all).

A good tip for using a Sign-off Agreement is to give your client plenty of notice before presenting them with the document. It looks kind of legal, so it may make a client feel as though they are being backed into a corner and are about to relinquish control over their project. It’s important to explain what it is early on, for instance, just before or after UAT.

Reviewed by Patras Surna. Rev. 02.