Software developers are often creative people, having entered into software development precisely because of its need for creativity during implementation. While solving a logical problem might sound unrelated to creativity, the ability to solve that problem in many different ways and choosing the right way, is what requires the creativity. This is what turns a mundane data entry job into an exciting and fun job.
Not only are there many different ways to implement algorithms or user interfaces, so that they provide the same inputs and outputs as required, there are many different ways depending upon the architectural or design view points taken. For example, should the implementation use as much reusable code as possible, or should the code be as simple, readable and hence maintainable as possible? Or is breaking architectural policy allowed, in order to ensure maintainability, productivity or other aspects, etc…
So if programmers, designers and architects are so creative, is it a problem? Well it can be, when requirements specifications are rigid. Developers need a certain amount of leeway in order to feel that they are being creative whilst doing their job. If a specification goes into exact detail about how to implement something (which a requirements specification shouldn’t actually need to do, unless the requirement is defining the inputs or outputs of the system), then a developer can feel there is no need for creativity, and the fun part of their job disappears quickly. Once that happens, developer motiviation becomes reduced and project success starts to suffer. Indeed a measure of software success is the level of developer happiness at the end, because you need these people to be motivated for the next phase or project.
The alternative to rigid requirements is a more agile approach. If the customer* can work with the development team in an agile manner, defining the outcome of the software together and allowing the development team to provide input on say usability aspects, or technological options, then everyone is a winner. The developers feel creative and the customer gets something which he can definitely use and definitely wants, because the agile process is an iterative one with short cycles between feedback and response (delivery of an updated version of the system). Often when writing rigid specifications, they suffer from "specification rot" (exactly the same thing as code rot, which is when code quality reduces over successive iterations of changes because new changes fail to take old ones into consideration). Basically said, the specifications become incomplete, containing conflicting requirements and illogical portions. Close and agile work between customer and development team allows rigid specifications to become living documents which can be adapted and perfected.
An advantage to the customer is also that they may become aware of other possible solutions to their problem. For example there may be a cooler way to make the user interface interact with the users. "Cool" can be a very important metric when it comes to web site design. Don’t believe me? Take a look at iPhone sales related to the "cool" factor. Developers may also offer better or more efficient ways to solving the customers problems.
Of course, there are two sides to any coin, so agile processes must have disadvantages. Here are a few:
– Scope Creep – the customer realises quickly with each delivery that they need something other than what they have specified. But I have experienced plenty of projects where the customer doesn’t realise that, until six months or a year down the line and by then all of their budget has been spent and it’s too late to fix the problem. At least in an agile process, the customer specifies through priorities, what is most important to them within their fixed budget, and that priority list is allowed to change as the customer discovers the system.
– Rigid release cycles – large corporations whose software is all interlinked may use say two fixed releases a year in order to synchronise releases and versions of software in order to reduce the complexity of running multiple versions of the same software at the same time. While such strategies do indeed make sense, there is no reason why individual projects may not be run lean and agile. The customer can certainly be given access to their software frequently as it is being built. The excuse that the software is not ready because interfaces to other systems in the big release cycle are not ready does not fly, because otherwise the software could not be built until those systems are completed (using stubs, mocks or similar are the solution here).
– Reluctance to change – many customers who have aquired software in the past only know how to do it using rigid and old fashion methods. It is quite human to dis-like change and go with what you know. But I encourage you to try going agile on your next project, even if it is only to prove me wrong, that agile projects are more successful than rigid ones.
– Inexperienced customers – to be a useful and good customer on an agile project requires that you are open to change and suggestion. Many customers create a picture in their mind of what they think they want and define that in a rigid way. They are afraid that if their rigid requirements are not implemented that the software will be wrong in the end. Well here’s the news: it will be anyway! There are very few individuals out there who a) know what they really need without going through an iterative cycle of trying it and then improving it, and b) who even if they do indeed know what they really need, can communicate it so that it gets implemented that way. So instead of going through the disappointment of only playing with it when its finished, try playing with it as it comes to life, just like a new home owner inspects their house as it is being built, or an engineer tests their mechanics as they are built. In aeronautical engineering, the "customer" is generally considered to be the company designing the new plane, rather than airlines who purchase the planes. No aeronautical engineering outfit has ever built the entire plane before testing that the waste disposal systems worked as required! Indeed such systems are put through acceptance tests before they are even integrated into the airplane.
Out of these, the two important ones are inexperienced customers and scope creep / change. Prioritising EVERY TASK on the project is the key to keeping the project on track. Experienced customers know that arguing over the layout of the UI down to the last pixel while important, may be costly. They can decide if it is more important to the project (note: not them as individuals) where the priorities lie. Experienced agile developers know this too and together the customer and developers can ensure a successful project.
So, as the world moves on, there are still many non-agile and rigid projects happening throughout the world. If you are in charge of software requisition and have some budget to start a new project, why not try making the project an agile one, if only because the creativity involved makes it a more fun project!
*
Let’s quickly define a "customer". In the sense of software development and aquisition, this group of people are the stake holders who are paying for the work to be done. They are not the users although should be part of that group in order to be able to specify what is really needed. In a world where a software product is to be built which will be sold to users, for example like what Microsoft’s core business does, the customer here is not the end customer, but rather the group of people who decide what should be sold in the first place. The customer group typically includes business types who are in charge of the money and strategy, as well as people representing the user community.
Copyright (c) 2009 Ant Kutschera
