Agile, A Double Edge Sword

Agile is a very useful development methodology especially for software development as it gives Project team, flexibility to incorporate early feedback from beginning till end of the project. Unlike Waterfall methodology it is not constrained with rigid phases and provides a good amount of flexibility to Project Managers and team. In waterfall methodology for instance, complete design has to be completed within design phase and any feedback on design from further phases cannot be easily incorporated as waterfall assumes that all phases will be completed in totality. Agile methodology on other hand is more realistic approach and provides flexibility to incorporate feedback throughout the project cycle. Agile methodology also gives flexibility to start early development even when the requirements are in process of gathering. For example, if requirements of only 20% features are known at the beginning of the project, then also team can start development of these portions in a sprint without waiting for 100% requirements to be available. As team can gathers remaining requirements, remaining features can be built in in later sprints, which also enable early feedback mechanism.

Ability to start project with partial availability of requirements is one of the greatest Power which Agile gives to Project Managers.  However this power has to be used with care by Project Managers, else this power can prove to be a weapon for self-destruction. Managers and scrum masters should not confuse partial requirements with incomplete requirements. When I say partial requirements, I mean that if a Team has to build an application which would have features 1 to 10; and if team has full understanding of requirements of feature 1 & 2 then team can start building feature 1 & 2, without waiting for finalization of requirements of all 10 features. However if team has let’s say only 20% clarity of requirements for features 1 & 2, then these requirements are still incomplete to start any development. Any attempt to start development of those features, for which requirements collection is not good enough will result in chaos, too much of rework and slippage of project timelines. Remember, doing development without fairly understanding requirements is like going on a hunt blindfolded. Managers may sometime find “Team Utilization” as a compelling reason to start early development even while requirements understanding is still in a very early stage, but they should remember that starting with incorrect and incomplete requirements will eventually result in too many reworks and productivity loss for rest of the project, which will add up to higher costs and delays. Managers also have to be careful that Agile Methodology should not be used as an excuse by customers or solution owners to give incomplete requirements.

Another difficult choice is whether to do design of backlog items within a sprint or before the sprint in which these backlogs have to be developed. Agile strongly suggests that before a team starts working on a backlog item in a sprint, they should have clear understanding of activities and tasks to be done including what classes and methods to be developed, etc. Team should also know how much time each activity will take, as Scrum Master has to match the effort required to complete the tasks with available capacity of the team. Before design is completed or at least high level design is complete, team hardy has an idea of what all classes and methods need to be written and what will be the exact effort. Only after designing is complete, team can provide a fair enough estimates. Thus it is very important that design is done in previous sprint for those backlog items which are to be developed in next sprint. If team is planning to do design in the same sprint then certainly there will be surprises and heart breaks and team will seldom meet its goals.

Agile methodology provides flexibility in execution with an objective to start early and also to get early feedback. Every methodology including Agile has its limitations or boundaries, If Agile is misused or over stretched and is used as an excuse for not writing clear requirements then consequences  will be disastrous for the project.