Everybody looks forward to the birth of a baby in a family, we want to know what gender the baby is, the complexion, the size, the looks etc. While we are all eager to meet the little one, there is no-one who is more anxious than the pregnant woman herself; the woman who had carried the baby in her womb for months.
The same way a software development team looks forward to the launch of the software product they had worked tirelessly building. Most of the time, schedule do slip but the “comfort” lies in looking at the efforts committed into the application over the project duration, and having this to say “we are closer to the end than when we started”.
And then, coding activities comes to an end marking the end of the software development efforts, the Project Manager with so much excitement sends out the announcement and then a User Acceptance Test (UAT) is scheduled after which the customer is expected to give a go-ahead for the product release. Wheew! The customer acknowledges the fact that the software was built the way it was described months ago but then it just doesn’t fit; it won’t work for their business.
Many a time, the software development company becomes apprehensive at this point. “What didn’t our business analyst get right during the project kick-off meeting?” the CEO asks. A “smart” Project Manager at this point would often bring out the signed requirement document where the customer with his signature confirmed the requirements and gave a go-ahead for implementation. Then the Project Manager is applauded for doing a good job of documenting all the plans of activities, the sales team is happy that they have a document with which they can “claim payment” for the software development bill charged to the customer especially when full payment had not been made up-front. “Was he sleeping when he signed the requirements” they seem to continually ask.
The customer on the other hand who was once enthusiastic about the product struggles to find value in the “useless” software that had just been built. In all of these, relationships go bad; putting an end to future benefits that could come from the project either through more contracts from the same customer or referrals.
The Waterfall/Traditional software development method is always prone to the scenario described above neither because the business analyst communicated a wrong set of requirements nor the customer was sleeping when confirming the requirements, it is just because requirements have changed over time. While changing requirements are seen as impediments in the success of a software project from the traditional project management standpoint; it is the exact reason why Agile Software Development methodology is agile.
The Agile method have a lot of practices that ensures that the software being developed is utilised as it focuses on delivering value to the customer, we simply do not want to build a software but we want to make sure that the software solves the identified business problems.
Here, I examine some of the practices of agile that have worked for me when managing software projects:
Customer’s Involvement: the customer works closely with the development team, making clarifications where and when necessary. When schedules are going bad and there is every possibility of missing the deadline, the customer can help the situation by prioritising the features to be implemented at that point in time, thus ensuring that the team is able to deliver on the features that are most important to the business.
As developers, we tend to feel a big sense of relief when customers leave us alone and do not interrupt our work during development. Keeping customers away while we develop the software does more harm than good if you would ask me, especially when automating a process that cannot be definitely described. The justification for keeping them away is based on the fear of scope creep, but the truth is; customers may find it difficult communicating requirements up-front, but they definitely know when you have got what they want!
Planning is based on the features not on tasks: the schedule is based on which features will be released at what time? In a typical waterfall system, schedule is prepared based on ”what activity is next?”. A business analyst for instance would look at the schedule to know when he/she is needed to analyse the product and when analysis stage ends, he/she hands off but in the agile methodology, the business analyst looks at the schedule to determine what features he/she is required to continually analyse in a particular period.
Short Implementation Period: If you have delivered a project in phases, you would agree that it’s easier to capture the requirements with more understanding; this practice comes natural to an agile methodology as implementation is done in short periods of 2weeks- 1month known as Sprint.
Iteration: iterations are built into the agile planning giving the development team to build a product that is near perfect at every iteration. This also provides the opportunity to accommodate customers’ feedback seamlessly.
Assigning Responsibilities to a team and not to individuals: “you failed to catch the bugs”, “you are responsible for putting the bugs there in the first place…” how many people are familiar with similar conversation between the QA engineer and the developers in a traditional software development model? The entire team own the success and the failure of the project in an agile environment because the delivery of the features for a particular sprint is the responsibility of the entire team and so, they all work together sharing their knowledge and expertise on how to make it happen rather than spending expensive time pushing blames or claiming glory (which builds an unhealthy competition) as the case may be.
Every business adjusts their strategies to keep up with the dynamic market forces; business processes change, technology changes even more. When software development is expected to span over a long period, a change in requirements to accommodate the processes that have changed should be expected in order to deliver a product that will be useful after all.
The traditional model is just perfect for some types of software project, but in situations when requirements are vague or complex at the beginning or when it is impossible to describe them with 100% accuracy, when project duration is expected to be long, the agile methodology is simply the way out.
Project Managers should know when to use either method – developing software that is eventually abandoned by the customer does no good to anyone, be it the customer or the software development team.
NOTE: This article looks at ONE common reason why software could be abandoned by the customer, there are other reasons.