Agile currently is an established and widely accepted methodology for software de­velopment and maintenance. Agile was designed with the tech industry in mind, and like its name suggests, it focuses on a speedy turnaround and an ability to adapt to changing parameters throughout the project’s times­pan. Today, every other project in the industry follows one or the other process of Agile like Scrum, Kanban etc. However, this has been observed a lot of times that Agile is “Half” or “Incompletely” implemented. Agile meth­odology is a strong way of writing/maintaining software but it is dangerous when implemented partially. There­fore it becomes imperative to understand some common reasons of partial agile implementation.

Selection of Wrong Methodology Itself

Firstly, we need to be certain on what the correct meth­odology for our project or assignment is and whether it aligns clearly with the goals. Agile is aimed at executing tasks faster, adapting to changes easier but may not be the best solution in every given context, therefore using a methodology selection matrix can help. In case Agile philosophy is best suited for the project, it is critical to identify the right methodology for the job. Many teams blindly go for Scrum even though Kanban / Lean may be the better choice. Although many companies are cur­rently implementing or leaning towards these modern methodologies, usually there are only a few people in the company who understand the whole process from A to Z (they usually are the scrum master or lean manager). Therefore, once we pick the wrong methodology, we will keep trying to force fit our requirements into it and hence Half Agile becomes unavoidable.

Waterfall Mindset

Agile (Scrum) does not’ mean just deliver “something” after a sprint. This is not about breaking up waterfall into smaller pieces. We typically observe teams delivering “architecture design” as an output of a sprint, which is precisely not the correct way of working in Agile. Every sprint should have something that is valuable to custom­ers. Breaking up Waterfall phases in sprints will only lead to Half Agile implementation.

Lack of Discipline and Commitment

Agile needs a high degree of discipline and commit­ment. Teams working need to work as a single unit and should keep their commitments at all times. At times, individuals might nonchalantly not align with the time­lines in mind, which puts pressure on others and in turn puts the project at risk. All sto­ries and sprints should follow ‘defini­tion of done’, team should respect the agreed time for meetings and discus­sions, a decent demo after every sprint are few examples where teams have a sloppy start. Whatever you do; without discipline and commitment, Agile will remain half!

Dependency on Tools

As a general practice, teams pick tools available within the organization and start using it without understanding of basics of Agile. There is no point of using tools if you do not know what is the burn down chart, how to create/maintain sprint etc. Tools can defi­nitely help you, provided you have a good understanding of Agile frame­work first. Even, a simple excel sheet can fulfill all basic need of any Agile implementation.

Not all Stakeholders are on the Same Page

For a successful Agile implementation, all stakeholders (team, management, customers etc.) should be on same page. All stakeholders having different expectation or methodology in mind is a major cause of Half Agile implemen­tation. If client/ management are not in support of Agile, there will be lack of coordination and support which is indispensable for a smooth Agile implementation.

Silos in Working Environment

Many developers and testers love to work in silos as they have been doing the same in the past. However, Agile needs co-ordination and communication at every step. Agile is a synonym of team work and silos will only con­tribute to keeping your Agile environment incomplete. However, another aspect of this which has been observed overtime is many teams find Agile helps them to both improve productivity while allowing them to boost crea­tivity and create unique solutions which is a win-win for both client and the team.

Developer Driven Estimates and Schedule

Generally, it is noticed that majority of estimates and hence schedule are developer driven; which is not always what works. Testing is an integral part of any output; sometimes test­ing efforts may be more than develop­ment efforts. Estimation and schedule should be decided by team after due consideration of all the activities; and should not be solely governed by devel­opment. Developers driven Agile team is a good example of Half Agile.

Lack of Automation Testing

Agile is an iterative model. Regression testing of previous portion is extreme­ly important. After a few iterations, without automation it is not possible to make sure that our previous work is intact and working fine. One might not need automation from day one but surely it needs to be a part of the plan as the project proceeds.

Scope Creep

A general misinterpretation in Agile environment is that there is unlimited ability to revisit scope. In fact, Agile project’s success depends on incremen­tal completion of scope with every spring throughout the life cycle of pro­ject. Hence, it is extremely important for teams to understand that they de­fine their “acceptance criteria” for each story and stick to that, otherwise they will never get real closure on work in progress. This leads to endless cycles of revisions that are really scope creep but which are not labeled so.

Conclusion

Agile is a very hands-on approach, especially for stake­holders and project managers. If you prefer to step back and let the process work for itself, this might not be the methodology for you. Half Agile will not help us in any way but will pour us with all negative aspects like scope creep, delays, poor quality, and adverse im­pact on business. Therefore, either we follow it com­pletely or we do not attempt at all for an Agile imple­mentation. Only full Agile implementation will lead to the benefits of Agile. Hence, be careful, analyze your Agile implementation today, and ask a question with yourself “Are We Half Agile”? If answer is “YES”, “ACT NOW”!