Most software projects are behind schedule, over budget, and “to add insult to injury” they often don’t even meet customer objectives. But why the poor project management performance? The culprit is they are plagued with changing requirements. There is hope for software project management though in software project management principles collectively called Agile.
The problem of changing requirements is, in particular, exacerbated in software projects by the fact that most software projects involve the application of new software technology to new business processes. Software development often concerns the automation or semi-automation of these new businesses processes. And if these business processes are not well-understood or clearly defined than the end result is an evolution of business process clarification and, inevitably, requirements changes. The effort to invent the new business process itself may be a failed effort. Simply applying the software technology maybe challenging enough.
The complexity of the software may lead team members to focus on the software technology first and business function much later. Most often this leads to a software solution that does not solve the original business situation, which is the whole purpose of the project.
The core problem software projects face is, again, the continued changing of requirements. Uncontrolled changes or continuous growth of scope is generally referred to as scope creep, which good project managers discourage and control. However, the nature of software projects makes requirements scope definition particularly difficult for the customer.
Agile is a set of software project management principles that seeks to meet the customer, perhaps, half-way by trying to accommodate the evolution of software project requirements.
Books have been written on ‘Agile’ project management, but the intent here is to provide the briefest introduction to Agile to explain its minimum core principles.
We begin our short Agile journey with a visit to the source material for Agile. This is the “Manifesto for Agile Software Development”.
This manifesto lists twelve principles of Agile Software. The first three of these principles, in particular, have a dramatic impact on management of software projects:
- 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.
The first principle and goal in Agile management is to deliver the most value as fast as possible. This early delivery of software value principle is closely intertwined to the third principle: the frequent and incremental delivery of value approach. If your project is say 20 software features you would deliver the completed first 10 features earlier. Partial incremental delivery is not, however, always realistic.
The classic example is an airplane control system. It would be insufficient and unacceptable to deliver a partial flight control system that could only control the tail rudder or yaw, but not the wing flaps or lift and drag. Many times, however, delivering features in stages is not only possible but provides significant value early on. Agile encourages investigation into the possibility of more rapid incremental delivery of features.
The question then becomes how big or significant should an incremental feature be before release. Thus enters the concept of a minimal marketable feature (MMF). An MMF is a feature that is the smallest possible and yet still able to provide value greater than the delivery cost. MMFs make incremental delivery possible. The challenge is how to break up overall system functionality to deliver the greatest incremental value early on.
Again, the Achilles heel of software projects is their continued evolution of requirements. In the second manifesto principle Agile developers seek to embrace this changing requirements environment. Further, the third principle, incremental delivery, makes embracing requirements change less painful.
Requirements changes come about because customers often do not know what they really want until they see a demonstration of their software in action. Agile seeks to acquire customer feedback on what they really need as early as possible. The process is therefore to design a small portion of the software, show it to the customer, who then gives feedback about it. And the features you present to the customer do not necessarily have to be field ready, just demonstration ready. Again, seeing their product in action provides the customer insight they can communicate in updated requirements.
You also want to begin your software development focusing on the most important functions of the system. Fortunately, this tends to coincide with a customer’s knowledge of their system. What are important and known to the customer are generally the key aspects of the system. So begin with the features the customer thinks are most important. This helps development teams target the most important system functions.
Agile approaches are a divergence from the common waterfall project management method. In the waterfall method you first complete all requirements for the whole system. Second you do all design. Third you code the whole system software. Fourth test the code. Every feature is done all together in phases. The entrance requirement of a successor phase is the completion of all features in a predecessor phase.
Figure 1 displays the waterfall method.
As work progresses to the right, all work for a stage finishes before the next stage begins. In the waterfall project management approach all features enter in and out of each phase together. Note, in particular, that no feature is completed until the end of the project, as validation of all features is deferred until the project’s last phase.
Agile does not measure progress in phases. Working code or features is its measure, as the third principle encourages: “deliver working software frequently”. Project status is reflected in the amount of code demonstrably working. Figure 2 shows the Agile approach.
The big difference in the Agile method is that features are built one at a time, and not altogether. Each feature proceeds through all phases (analysis, design, coding, testing, and possibly deployment) by itself. Once a feature completes all stages then you turn to the next feature. And validation of features is done more frequently.
It is believed that by individually coding each feature through all stages of product development problems will manifest earlier. In Agile it normally is planned to take a few weeks at most to develop a feature for customer verification/certification. So feature problems are found after a few weeks of work in Agile verses possibly months with the waterfall approach.
The Agile approach to software project management is in a way like managing a mini-project lifecycle for each individual feature. In each iteration Agile delivers smaller and more important features through the software development pipeline.
Agile also provides earlier feedback of functionality, because the single feature iteration time through this development pipeline is significantly less than the time required to bring all features through when the system is taken as a whole. And Agile embraces requirements change, which are updated at the end of each feature’s mini-project iteration. However, scope creep is controlled by either more precise requirements and/or removing items from the requirements list.
Agile better predicts progress because the measure of success is working code. Again, Agile incremental delivery approaches may not be appropriate for all software projects, but having the discussion and exploring ways to deliver business value faster is a key aspect of Agile.
To reiterate, Agile is more of a philosophy of development based on core principles rather than a specific methodology. There are, however, numerous procedural approaches that employ these Agile principles. One of the more popular methodologies is called Scrum. Some of Scrum’s basic procedures are the following:
- Time-bound increments called Sprints
- Delivery of Incremental working (done) product features
- Sprint review where customer provides feedback
- Adaptation of changing requirements to product backlog
The Agile principles are evident in these Scrum procedures. Many books have been written on Scrum and other Agile methodologies, and are a topic of discussion for another day.