The Customer is Not Always Right
The Customer is Not Always Right
Sometimes, when you're an agile product manager, you can't listen or cater to customers.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
“The customer is always right” has usually proved to be sound advice in business. For example, you’re a house builder and your latest development is running behind schedule. You can either finish late (and possibly incur financial penalties, a damaging dent to your reputation and subsequent loss of business) or you can throw more resources at it (albeit costing more) and complete on time. In fact in traditional manufacturing businesses it is usually possible to throw more resources at the build phase of a late running project to bring it in earlier. This works for two reasons:
The build phase is often done by many people doing similar jobs (in our house building example, bricklayers, electricians, plasters, roofers) where adding more people means more work is done in parallel.
The build phase of the project is the most time-consuming part of the project timeline so provides the most opportunity to tackle late-running even if the cause of the late-running was in a prior phase.
However, this does approach doesn’t translate well to the world of software development, and the reason comes down to a common misconception: that the build phase of a software development project is the coding; it’s not, the build phase is actually the compilation of the source code into a deliverable application, an operation that (unlike in other industries) is almost cost-free and relatively instantaneous.
This is not just arguing over semantics, there are very real consequences for project management if this misconception is perpetuated. Going back to our house building example, if you need to build five houses and have resourcing to build one house at a time then you can work far more quickly by hiring extra workers to work on the other houses in parallel. Assuming they are experienced workers they will be able to apply their skills immediately (laying bricks in one building project is similar to laying bricks in another), and a significant increase in building rate will be achieved. The extra workers are not tackling a fundamentally different problem to the last one they worked on and they are not being asked to design anything, simply to apply their existing skills to an existing plan.
Conversely in the software industry the programming phase is far more aligned to the design phase in traditional manufacturing than the build phase in a traditional industry. If coding were simply a matter of typing in code supplied by the project architect, it would closely resemble a traditional build phase, and adding more typists would reduce the time taken for this phase. However, programming is a fundamentally creative process, usually involving a good deal of thinking and an iterative cycle of changes, testing and refactoring. Even if a detailed design is provided beforehand, it is in the coding phase that flaws will be (and usually are) found and the design changed. In fact, I would argue that the code is really the design (see http://www.londoncoders.net/what-is-oo-design-and-do-we-need-it-in-an-agile-environment for more detail).
Why does this matter? Well if your project is running late, one suggestion your customer (or your manager) will come up with sooner or later is to add extra developers. While superficially this might seem sensible (and hard to argue with), I would argue that it should generally be resisted. While small numbers of extra developers at a relatively early stage of development may help, it may also hinder, and adding large numbers will almost certainly slow down the rate of progress (also known as Brooks’ Law). Why? Because a new programmer cannot simply repeat what he/she did on the last project. The problem to be solved will usually be different, there may be different technologies involved; in short, there is a learning curve to be travelled before that programmer can become a useful team member and until that time will be a drag on the project. The more newbies you take onboard, the more of your team’s precious time will be devoted to educating them rather than to writing software. And the later you add them in the project cycle, the smaller will be your return on that investment and the more likely you are to miss your deadline. This is not obvious to most customers (indeed, in my experience not even to many IT professionals) but it is crucial that they understand it to avoid piling on more delay to an already late project.
So how do you get your project back on track, if adding more developers is not a solution? Let’s start with what not to do. Putting in quick hacks to make a feature work will almost always bite you in the backside later when you need to extend that feature and the only way to do it is to rewrite it properly. Lowering standards also reduces a team’s pride in its work and sets a precedent for other features and you will start to see code quality degrade, and maintanence overhead start to increase. Similarly you should not skimp on the testing in order to get a feature developed. Reduced test coverage leaves holes in the project into which bugs will slide silently, reducing the confidence with which you can refactor and increasing the maintenance effort.
A better approach is to avoid getting to a late stage in the coding phase before discovering that you can’t make your deadline. To address it early you need to be able to track progress accurately from the start, so you need to set frequent milestones, by which you can gauge progress. If the milestones start to slip, then you can extrapolate from the delays there to the delay on the project as a whole and start taking action early – adding extra resources, removing administrative burdens, negotiating a new deadline, or a reduced scope.
In order to use milestones effectively, short release cycles (2-3 weeks) are essential, with each release representing a milestone. After each release you can assess progress and potentially release the software to your customer or at least demonstrate what you’ve done. This approach also has the significant benefit of getting early feedback on the product so far, allowing you to make changes early on — far cheaper than remediating this after releasing the final product, and much more satisfactory from a customer perspective. Regular progress updates with the customer also provide a natural point to broach any issues related to schedule delays and to work with the customer to reassess the priorities for the next stage. If you’ve read this far, you’ll probably recognise this use of short development iterations, frequent customer feedback, and delivery flexibility as key principles in Agile development — a methodology that implicitly recognises differences between the software development lifecycle and more traditional product manufacturing lifecycles.
Opinions expressed by DZone contributors are their own.