Monday, 19 November 2012

Agile Principles for Software Development

 - Mr. Jagadish Shri

Mr. Jagadish manages our program in Mysore. He has over 20 years of experience in the IT sector.

Let us start with a bit of background.

Process of Designing Software
Generally in software based on a set of user requirements, a design is made breaking it up into modules. These module designs are then handed off to an implementation team to code. These are then individually tested. Subsequently these are put to together as a system and tested and finally handed off to the user. All this sounds fine in theory but a software project in real life did not work this way. As modules are being put together issues would come which sometimes meant design had to be changed. Several issues would come up with user testing the product which meant requirements were not fully understood and so on. All this leads to a lot of heart-burn and finger-pointing between the various stakeholders in the project.

It was traditionally assumed that the fix to these problems was to have better requirements documentation (with a signoff), better design documentation etc. The underlying motivation was to make it safe for the respective groups or make it easier to fix the blame for failure later on. Eg: As long as I conform to the design specs given to me I am safe; nobody can point fingers at me. Fundamentally there is a challenge with communication in general, and trying to document everything in a written form (which is actually less powerful than face-to-face communication) adds more to the challenge. Also the traditional approach stems from a basic distrust between the customer and the supplier and the need to somehow "control" the other party through the documentation process. This extends across teams within the project too (design team v/s implementation v/s test). While all groups could maintain that they have conformed to their specific roles and their documents, there could be holes in the overall product which are "nobody's fault".  Finally, many a times it would turn out to be a case of "operation successful, patient died".

Agile Movement
The Agile movement started off as a response to these challenges faced in software development.
The Agile Manifesto puts more value on individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.

In life we see that for things that are less transactional and of higher value / importance we go more by referrals (a form of trust building) eg: consulting a doctor.  Or take the case of building a house. You cannot handover a blue-print of the house and go there after a year and expect the house to be ready just as you had it in your mind. If you care for the outcome you have to get involved. The more involved you are the more likely the final product turns out the way you wanted it. Even if it is not exactly that, you know the reasons why.

Agile thinking applies the same logic to software. It is difficult for a user to visualize all requirements and scenarios upfront. Further, it is difficult to communicate this to the development team. The same applies with the development team. Instead of trying to nail down all requirements, a critical few can be identified which the software development team works on and quickly delivers a usable product. This has to be in a short cycle referred to as a time-box or a sprint typically of 1 month duration. The customer/end user starts using the delivered product and gives feedback which forms the basis for the next sprint of development along with the next set of features. So development happens in a rhythmic cycle where the amount of development that can happen in any time-box is fixed but what features get delivered is varied in each cycle based on customer feedback. There is discipline in the sense nothing can change in the middle of a time-box but since the duration is short there is a better chance that the user is ready to wait until the next window for the feature that they now require. The idea is to take the hard problems and tackle them upfront. Eg: integration across modules, across vendors. Communication is a problem - so have more communication and feedback right from the beginning. Working software is the most concrete evidence of progress made (while documents serve only as proxies). So have that right from the beginning and let it evolve as the understanding evolves.

One key aspect for this model to work is that there has to be trust between the users/customer and the vendor. The customer has to trust the vendor enough to understand and accept certain constraints and limitations that the chosen platform puts on the solution. Similarly the vendor has to trust the customer and understand the need for certain features to get added / modified or changed during the course of the project. This trust also applies to the various development teams involved which might be in one location or distributed across geographies and vendors.

Agile projects run as long as all the features as decided by the customer get delivered or the time/budget runs out. The prioritization which happens at the beginning of each cycle ensures that the most important features are there.

Putting it into Perspective with this Project

So taking the example of this project, an Agile approach would be to work with one or multiple vendors wherein the team (which includes all - users, development teams) identifies one lesson. This has to be delivered (which means the user should be able to login, navigate view all resources associated with this lesson, reports are generated related to the user login) in a short cycle. The user sees what is delivered and then the work continues with the next lesson and so on in cycles. Based on the experience of this one cycle certain decisions like vendor selection could be made.

Does this mean software development will be a bed of roses after switching to Agile? - Definitely not. It only means that the issues that haunt software projects towards the end are taken up head-on in the very beginning and tackled. This should make the progress a lot smoother in subsequent cycles. As the cycles progress the understanding across the stakeholders improves - users understand the constraints imposed by the platform and technology, the cost/effort versus functionality tradeoffs, developers understand user needs better and so on. At the end of the exercise the output should be a lot closer to what was envisaged by the user.