PITFALLS TO AVOID IN AGILE PROJECT

Agile projects are everywhere now a days. While the concept of agile development has been around for quite a while, these days, everyone wants their project to be executed in agile manner. However one needs to keep in mind that agile methodology works best in certain scenarios where as it can lead to failures if force fitted.

Selecting the execution model

Is the “agile” model being selected just to start a project without giving much thought to the product specification? Or to avoid planning or processes? If that is the case, beware!

Many times, agile development is selected because it’s “cool” or has flexibility on documentation, processes. However one needs to keep in mind that the project’s timelines or budget are not that flexible. So, if you have one of the above mentioned reasons to select this model, think again.

Agile model has lot of advantages, if the project is suited for and executed in the spirit of agile model. However, if the model is not selected thoughtfully, it can also lead to issues.

Selecting the team

In agile model, team is very important and empowered to take decisions. Be it backlog prioritization, estimates, planning of sprints, individuals working in the team need to have the right skills and decision making ability. It is important that each one on the team has the big picture in mind and always strive to own up the decisions. Also the agile teams are self-sufficient in terms of skills required for the project. So you need to have business analysis, architecture/designing, development technology, QA/QC skills within the team (not necessarily different people for each skill). In addition to these technical skills each team member needs to have good decision making, risk analysis, communication skills. One also needs to ensure proper utilization of team in terms skills and time. If you are going to have team across multiple locations (not co-located), then that throws up different set of challenges (this needs to be discussed in detail ...some other time).

If you are moving from traditional models, this thinking is many times missing in the team members. It is better to orient team members to agile way of thinking.

Requirements

Agile manifesto prefers “Working software over comprehensive documentation”. This does not mean “no documentation”. You need to have a product owner who is the authority on requirements and will create product backlog, acceptance criteria. This should include the complete wish list of the product to be developed. It gives the big picture to the team of what needs to be built. While the team prioritizes the backlog, it should not forget on what might come next so as to provision for it in the product. If there are not enough items in the backlog, it can lead to under-utilization of the team.

You also need to be careful with handling changes to the requirement. Though the manifesto states “Responding to change over following a plan”, one needs to keep in mind that neither the project budget nor timelines are infinite. While the agile project should be able to incorporate and adopt changes, it does not mean one should throw away plans. There needs to be due diligence of the impact of changes on the plan and ensure it gets communicated to all stakeholders.

Designing the system

Will this model work if you make non-extendable/rigid design of the system? Team has to make sure the design of the system is simple and flexible to accommodate future changes. At the same time one should not go overboard to make it too generic, as it can lead to unnecessary efforts. The trick is to balance the future needs and flexible design.

Quality Control

As the agile development is always churning out working software which is fit for use, it is very important to have complete control over quality of deliverable. The QA/QC has to ensure that the new features being added are working as per the expectations as well as earlier features/functionalities are intact (not broken). It is important that every individual on the team understands the changes that are happening to the product and its impact on existing features/functionalities and raise alarms if they see any risks. Ignoring known defects or piling them up in backlog can lead to lot of rework later, making the product unstable.

Communication

The base of agile development is “Interaction” and “Collaboration” between stakeholders of the project. This has to be on daily basis so that each one understands what is happening and where is it going. This is also applicable to the feedback from the customer. As the team releases product versions, there has to be inflow of feedback from the customer so that it can be incorporated immediately in the current and future work. The same is true for retrospectives which should be conducted at end of each sprint. A “thoughtful” retrospection can identify issues and lead to improvements in project.

Organizational Processes

Many organizations need every project to follow certain processes and expect specific documentation. It may force even the agile projects to follow the same. This can lead to conflicts between the project and organizational needs. It is better to negotiate with the organization’s process group about what can be done and what cannot be done as part of the agile project. There is no point in forcing unnecessary processes on the project, however there can be ways to adopt agile processes which can satisfy organizational needs.