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.

Surviving An Under-resourced Project

How to cut development time on web projects that have a tight budget.

In the competitive world of web development, it's not unusual to be handed a project where the resources available are not adequate enough to achieve the results expected by the client.

A common reason why an under-priced project has been approved in the first place is because someone was desperate to sell a solution to the client. The result is a tight budget where features must be culled and SDLC processes streamlined.

For the sake of illustration, let’s say a client is given a proposal stating that their project will cost $20,000 to build. The client then comes back saying "that’s too much, I have a budget of $16,000 at most." It's not unusual for the person who wrote the proposal to be told "adjust the quote so it comes out to $16,000. We want this work."

We now have a situation where the project has to be undertaken with less money than is ideal. A tight budget isn’t necessarily a bad thing, but sometimes a project can be so drastically under-priced that it is plainly a bad business decision to accept the project in the first place (i.e. a doomed project). There are boundaries where it just becomes ridiculous; if the client were to say "my budget is $4,000", then the company couldn’t possibly take on the project.

Is there any difference in managing a project with a tight budget vs. a amply funded one? The answer is yes. In an under-resourced project all tasks which aren’t absolutely necessary are jettisoned. A big reason for this is so the company has some chance of making a profit or breaking even. Because of these cut-backs, an under-resourced project is often in danger of suffering serious quality consequences.

Since there is no such thing as a project with unlimited resources , the question then becomes a matter of what are the indicators of an under-resourced project. Let’s take a look at some typical tell-tale signs:

• Bare minimum amount of time allotted to QA
• Overly bureaucratic process for change requests and off-spec work
• Change request budget may be small or non-existent
• Formalized processes get dropped to use time for development
• No time for value-add QA like grammar or spell checking
• No allowance for hallway usability testing
• No on-site installation or support (phone or email support only)
• No budget for writing user documentation
• No face-to-face user training
• Documentation which is out-dated
• No technology research ('good enough' coding will have to do)
• No time to produce a risk analysis document
• Poor or barely existent project schedule
• Coders don't track their actual time taken for tasks in the schedule
• Company perks disappear (e.g. food, beverages, etc)
• No down time - time sheets reflect 100% allocation to project work
• Progress updates for clients become infrequent and rudimentary
• Less time is spent understanding the business domain
• Programmer have to work unpaid overtime
• A project post-mortem isn't conducted (i.e. lessons learned )

You may notice many of the compromises are quite minor. And there is a reason for this. Under-resourced projects exists at the border line between a project not going ahead at all, and one just barely being ratified. If resources and processes were cut to an extreme level, then the project would be destined to fail no matter what (e.g. a project with no functional spec or project schedule isn’t under-resourced, it’s just plain old crazy).

For project managers finding themselves at the helm of an under-resourced project, there are a few strategies which can be used to not only deliver the project, but also maintain an acceptable level of quality:

Minimize iterations - the more it goes back to the client for feedback, the longer it takes. I know this flies in the face of modern Agile practices, but what I’m saying is to limit the feedback cycle, not abolish it. What does this mean in practical terms? It equates to establishing ground rules with the client early on (e.g. only allowing three iterations to get the wireframes correct). Could this be construed as under-servicing the client, perhaps. But it may also force the client to be decisive rather than relying on iterations.

Use informal sign-offs - use email as much as possible as a sign-off medium. For example; you may send the client a JPEG of their website design and ask them to reply with something along these lines: "I approve the design". It’s a simple time saving strategy because it always takes longer to get a physical signature from a client. Getting informal sign-offs also reduces iterations since the client knows they are officially locking in a decision.

Maintain a production checklist - on a smaller project involving just one or two people, time can be saved by using a production checklist rather than a full-fledged project schedule. A production checklist is just two items in an excel sheet; task and percentage complete. It says nothing about estimated hours. Couldn’t you just drop the production checklist completely and save even more time? Sure you could, but then the chances of missing something becomes a real danger. Back-tracking to include a forgotten task could take more time then the investment in making the production checklist in the first place.

Use passive reporting - instead of chasing programmers to ask where they're at with their tasks, get them to come to you. This can be achieved by asking team members to update their areas in the online project schedule twice a week. Another way is to get team members to email you when they have a deliverable to report (e.g. "the SSL certificate has been installed. I have a confirmation email from the hosting provider").

Propose staged development - if a client has a big project but not enough money to get it done, then suggest they break up the project into a number of stages. The initial or 'core' stage would include the most vital features which they simply couldn’t do without. Later stages would bring in the nice-to-haves and value-add features.

Use a bug tracking system - generally speaking, you should be using a bug tracking system anyway. But it becomes particularly important in under-resourced projects since all time expenditure needs to be allocated with great precision (i.e. there is little room for error).

Use mini-specs - once coding begins, chances are good new features will be requested at intermittent points during development. Rather than adding features during the main development cycle, gather them together into a mini-spec. The items in the mini-spec would be implemented after the originally scoped product is delivered (possibly taking it to version 1.1). By not adding features in drips and drabs, you are optimizing integration.

Do 'feature triage' - be harsh on what features really need to be included in the initial release of the product. It may be painful for a client to accept that they can’t have the world on a shoe-string budget, but something's got to give.

Trim unnecessary tasks - instead of doing two rounds of system testing, do one. Instead of allowing for two on-site visits to conduct user acceptance testing, do one visit and the rest via phone. Do you really need to spend an hour worth of travel for another face-to-face meeting with the client or will a phone call do? If you are observant, creative, and ruthless, you will see many opportunities where time can be trimmed. Of course, hacking away too much will mar the product’s quality and just require time be re-invested for fixes.



A question which surely beckons attention is what impact a tight budget has on product quality. A client isn't going to accept an excessively buggy product in either a well funded project nor one with tight resources.

You can still attain a level of quality closely approaching a well-funded project. What it comes down to is things like how polished the system looks (e.g. amateurish icons vs. professionally designed ones). There could also be less relationship building with the client since there isn’t as much time for face-to-face meetings. A reduced QA cycle may uncover fewer errors, so the system gets launched with dormant bugs that surface later down the track. Successfully delivering a under-resourced project isn’t impossible, the trick is knowing what to trim and what to keep.

Subscribe to RSS Feed.