Anurag Agrawal, Director Engineering, GlobalLogic
Agile currently is an established and widely accepted methodology for software development 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 timespan. 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 methodology is a strong way of writing/maintaining software but it is dangerous when implemented partially. Therefore 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 methodology 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 currently 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 customers. 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 commitment. 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 timelines in mind, which puts pressure on others and in turn puts the project at risk. All stories and sprints should follow ‘definition of done’, team should respect the agreed time for meetings and discussions, 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 definitely help you, provided you have a good understanding of Agile framework 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 implementation. 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 contribute 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 creativity 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 testing efforts may be more than development efforts. Estimation and schedule should be decided by team after due consideration of all the activities; and should not be solely governed by development. 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 extremely 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 incremental completion of scope with every spring throughout the life cycle of project. Hence, it is extremely important for teams to understand that they define 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 stakeholders 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 impact on business. Therefore, either we follow it completely or we do not attempt at all for an Agile implementation. 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”!