Don' be Fragile! Be Agile! - Part one

The latest buzzword that’s doing the rounds in the Software industry is ‘Agile’. Even if you are not directly connected to the Software and IT industry, chances are that you must have heard this term a number of times. More and more software companies and teams are using the Agile method to develop and test software. Agile Scrum coaches and practitioners, developers, testers and managers who have experience in ‘Agile’ methodologies are in great demand these days.

But what is this ‘Agile’ methodology and why is it so popular? Why are so many IT organizations big and small switching over to the ‘Agile’ way of doing things? How exactly does ‘Agile’ function and what are its inherent advantages which make it so favoured? If you are new to Agile then I’m sure that these questions will be popping up in your mind frequently. With this blog, I aim to explain the ‘Agile’ way of doing things and unravel the reasons for its popularity.

To fully understand ‘Agile’ we have to look at the following points:

a)      The software methodologies used before Agile came into practice (Ex: the Waterfall model)

b)      How the ‘Agile’ model originated. What its’ salient features are (the Agile manifesto).

c)       What benefits do organizations, companies and teams derive by using this methodology.

Let’s define ‘Agile’ first. What exactly does ‘Agile’ imply? The dictionary defines ‘Agile’ as the physical ability to move quickly and easily. In mental terms, it means to think and understand things quickly. In the broad sense, it means to be positively responsive towards changing conditions and to adapt quickly. In other words, it implies flexibility and quick acceptance of change. This feature is the crux of Agile and the foremost reason why it is so popular nowadays. In today’s rapidly changing and evolving software landscape Agile helps teams respond to change more effectively by being more flexible and adaptable to changes in the product. And how exactly it does that is what I will cover later.

To understand how Agile came into place, let’s take a look at how software was developed before Agile. Before Agile, Software companies mostly followed the Waterfall methodology of developing software. The waterfall method is a linear way of designing and developing software in which each phase of the SDLC is an independent process which follows a linear path. After one phase is completed, the next phase starts and so on and so forth until the last concluding phase is reached. As indicated, Waterfall follows a straight path. Each phase starts only after the preceding phase ends. There is very little scope for phase overlap. The ending of one phase signals the start of the next phase and so on till the last phase is done. The figure below shows a typical waterfall process flow:

In the early days of Software development, requirements were more or less static and there was very little scope for change, if any. Well not exactly, but Software was more or less simple and the requirements were more or less straightforward those days with no frequent changes in scope and functionality. In a typical waterfall scenario, the effort would have proceeded in this manner:

a)      Requirement Gathering:

-          Client or BA(Business Analyst) team prepares the requirement documents containing details of the application / product to be created

-          Project team liaises with the Client / BA team to discuss the following app / product

-          Queries are raised by respective teams (Dev / QA / DB) etc. which are resolved by the Client / BA team.

-          Client signs off the requirement document after all queries have been successfully resolved.

-          This acts as the trigger for the next phase.

b)      Planning:

-          Planning phase is kicked off after requirement sign-off.

-          Dev / QA team create plans for their respective objectives.

-          Plans are reviewed and approved by stakeholders.

-          Planning phase ends. Next Phase starts.

c)       Design:

-          Design process starts after plan is approved.

-          Dev team starts coding / QA team starts preparing the test cases

-          Dev teams creates prototype of the app and runs unit tests.

-          Product is released for testing after Unit tests pass.

-          QA team reviews and sends test cases for sign off.

d)      Execution:

-          QA team conducts a sanity test and starts testing if sanity is cleared

-          Defects are logged and sent to development team.

-          Defects are resolved by Dev team.

-          After acceptance criteria has been met, testing stops

-          QA team prepares report and releases app for UAT testing.

e)      Closure: The QA team prepares a test summary report for reference to all stakeholders. The software is released for UAT after which it is deployed to Production.

-          QA team prepares Test summary report for all stakeholders.

-          Software is released for UAT and sub-sequent go live.

So as can be seen, Waterfall is a fairly simple and straightforward process.

Let’s take a real world example. Let’s say your company has got a project for making a desktop calculator application. You are the project manager and have the choice of choosing the workflow for making this app. Which approach will you adopt? The requirements have been clearly spelt out by the client. You have an experienced Dev and QA team to handle the proceedings. In such a case, the waterfall method is the best way. So you proceed in a phase to phase manner.

-         Your project team sets up a project kick-off meeting with the client. The client outlines his product scope and vision and provides the high-level requirements.

-         The BA team liaises with the client and prepares the calculator requirement / scope document.

-         Based on the high level requirements and the scope document, the project team clarifies requirements with the client. Once all requirements have been clarified, the client and the project team signs off on the requirement.

-         After Sign-off, the Project team begins planning phase. Respective teams prepare estimates and start the planning process. Risks and mitigations are identified and strategies are made for coding and testing respectively. Architects plan and prepare the architecture for the app.

-        The design process starts after the Planning phase. Development team starts coding and the QA team starts preparing the test cases. The dev team makes the first prototype of the app and releases it to QA after unit testing. Design phase ends.

-        Execution phase starts. QA team conducts a sanity test and based on outcomes determines further testing.

-     After execution is done and the test completion criteria is met, execution stops and the QA team prepares the test summary report.

It looks perfectly simple and logical right? I mean, what could go wrong with this one? Why all the hullabaloo over Agile when you can develop the product in a simple and straightforward means by Waterfall? Well, that’s because the software requirements were not very complex. Application requirements were clear from the start and there was very little scope for change. The team knew what to work upon and could thus, plan and strategize effectively for developing and testing the product.

But what if any change request came about from the client? Let’s say, the client requests another new button or tab or new functionality to be added. What then? Two factors would come into play in such a case:

a)      The Nature of the change request (How big is the request, how will the scope be impacted, what is the workaround required)

b)      When the Change request is made. A change request (or CR as it is abbreviated) introduced earlier can be effectively integrated into the cycle without too much workaround. If introduced at a later stage, it could be a cause for concern as it might lead to more product rework, re-coding, re-scripting of test cases etc.

Usually, the earlier the change request is made the better. If the CR comes in the early stages, the project team can calculate the necessary rework and impact to the current scope and schedule (which probably won’t be much since much of the work has not started anyways). The team makes the necessary changes in the plan for incorporating the new CR and work starts again.

If however, the CR comes at an intermediate or late stage of the project, then incorporating it would look a bit dicey. Here, the factors a and b mentioned above would come into play. If the CR is either too large in scope and / or comes very late in the project (ex: a scope change during the testing phase), the PM should not hesitate to point out to the client that incorporating this CR is a huge risk and should recommend adding it in the next release.

The typical risks associated with attempting to incorporate the new CR at a later stage of the project include:

-         Team will waste precious time in understanding the new requirement instead of focusing on existing tasks. Release timelines might get impacted.

-         It will lead to additional rework on the team. Attempting to add the CR within the given time-frame could lead to stretching the teams’ efforts to late nights. This would result in fatigue and low team morale.

-         The quality of the application will surely take a beating.  

All this will impact the PM and the teams credibility. It all boils down to the PM and his team on how firm they are in dealing with CR’s.

Taking the above example of the calculator, let’s say the client has come up with a change request. He/she wants a new button/function to be added to the calculator. You as the PM get together with the team and analyse the CR. On the surface, it seems to be a simple change. I mean, just adding a new button should not be much of a change right? Maybe, but there could be a lot of hidden factors involved. This small change might require some big and complicated changes in the Database architecture, code etc. So, after a fair amount of Brainstorming, you decide to add the CR. Your team says it’s a piece of cake and won’t take much effort. You know this team is experienced and have led this team before. So you agree to their decision. The CR gets incorporated and fortunately, things work out as planned. The new functionality gets added and the client is happy.

If the CR did require some serious amount of rework, the PM would have taken the call to postpone the CR to the next patch request or to add it to the current scope if the client was willing to accept the change in the delivery timelines due to the CR.

As seen above, the waterfall model can also add change requests pretty well. So why all the fuss over Agile? Well, in the above CR you must consider the following factors:

a)      The CR was not a complicated one. The team was experienced enough to handle it and the CR got integrated smoothly.

b)      This was a one off case and there were no regular and frequent CR’s requested by the client.

 

But what if you were developing a complex application? Let’s say for example, a web and mobile based social networking application (Similar to Facebook, Hi5 etc.). Such an application is complex in scope and is subject to various change requests. Would the waterfall model work well in such a case, or would it make sense switching to Agile?

That’s what we are going to analyze in Part two of my Blog.

Thanks for taking the time and patience for reading part one. Stay tuned for part two.

Regards,

Srinivas Pavan Addanki