The analogy I tried hard to make in my last few posts was to dispel the notion that software development is NOT like building a Car, or a bridge, or even a home. So let us as engineers and developers, move beyond that concept and begin to think of our discipline as more fluid. I know many in my field will not like this, especially on the east coast, but my ultimate goal is to think of us more as a combination of surfers, artists, psychologists, architects, and construction workers more so than engineers.
To summarize the problems we face with the current methods in the world of software development;
- Businesses Change – Let’s face it, we have all come to the conclusion in the last year or so that markets don’t always go up. They fluctuate and sometimes unfortunately they crash. Likewise Businesses are not always successful and if they are too inflexible to the market they will fail. To counteract this a good business is agile enough to handle the changing market conditions. With change, comes different sets of requirements, which current development methods do not handle well.
- Communication Is Vital – In today’s world as illustrated, though with a bit of humor, in the British Comedy “IT Crowd” software development teams, and IT persons, are often very far removed from the business. This makes it very difficult to communicate to those developing the software what the requirements are, as well as help those in the business understand some of the hurdles in delivering a particular requirement.
- Motivation – This is a tricky one. But let’s be honest with ourselves for a moment. Many people in general work better and are more focused with deadlines. Some people don’t always need a deadline, but it is safe to say a majority of people do.
- Inability to measure progress – In today’s world progress is measured by something called a project plan. A project plan is a nice little graph with tasks, and bars that show percent complete. The percent complete is usually just an estimate given to the project manager from the developer. In most situations, the Project Manager doesn’t have any idea what criteria the developer is using for the estimate given, but simply accepts what he or she is told.
Take a look at the Principles behind the Agile Manifesto and you can see how this method for software development addresses these problems directly.
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.Business people and developers must work
together daily throughout the project.Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.Continuous attention to technical excellence
and good design enhances agility.Simplicity–the art of maximizing the amount
of work not done–is essential.The best architectures, requirements, and designs
emerge from self-organizing teams.At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Directly each one of these statements of commitment deals with the problems in the current process, with the ultimate goal of a happier more satisfied user base. With all of that said however, I will admit that while this methodology has a lot of appeal to the software development community when discussing this with the money people there is some difficulty.
Mostly because the Agile method never portends to cut the development cost. By letting the scope of the project change over time, costs of development “might” in fact go up. I say “might” because there has been many projects that I have seen that are amazingly under estimated who end up having major overruns, and high costs of completion.
So one must weigh the cost of getting something “done” versus getting something “right” in making the ultimate choice.
It is my feeling, and the view of the Agile camp that this choice is obvious.
