Volatile market dynamics and the urge to adapt to ever-changing customer needs has led to the increase in Agile awareness. Businesses have started understanding the benefits of Agile and are proactively willing to join the Agile bandwagon by adopting Agile best practices. Market research has shown that a majority of teams start their Agile development journey by way of Scrum. But often, the decision to adopt Scrum or any Agile project management methodology for that matter is driven by incomplete knowledge of the core principles of Agile. They start their Agile transformation journey in full enthusiasm only to realize at a later stage that things are not working out as expected. As a result of this, many teams revert to their old way of working and end up claiming that Agile is not suitable in their context. In this article, we will discuss some of these delusions which hamper smooth Agile adoption.
Ideological Delusions hampering Agile Adoption
1. Reading about Scrum and following the ceremonies is enough.
Many teams take this route where the customer asks them to implement Agile for an upcoming project. They do their own research and jump into the thick of the action, often treating it like just another way of working. Reading about Scrum only tells them about the prescribed practices and not about the rationale behind them.
2. Adopting Scrum means faster deliveries
This is one of the most popular reasons why customers want to adopt Agile. Faster deliveries are possible with Agile and DevOps but the amount of groundwork required to achieve faster deliveries is, quite frankly, intense. Ironically, teams are instructed to start work on the project as soon as possible and also expected to streamline deliveries right from Sprint 1. Agile transformation process with fast, seamless and error-free deliveries requires careful strategizing, expert execution and patience.
3. We can do away with documentation as we are Agile
Agile advocates the reduction in wastage by shying away from the unnecessary documentation. But architecture documents, project plans, strategy documents, etc. which form the basis of future project activities cannot be omitted. Thus, the most important documentation has to be identified and maintained for the project. Documents which add no specific value to the project need to be identified and done away with.
4. A project manager can be the Scrum Master and “manage” the projects
Owing to the way projects are set up and billed, a lot of teams are reluctant to hire a full-time Scrum Master. Popular beliefs dictate that Project Managers can be Scrum Masters. Traditional project managers go along with their business as usual and Scrum Master just ends up being a designation on paper. The specific responsibilities of a Scrum Master are fulfilled to some extent but the concept of servant leadership never materializes.
5. All communication between teams should be in black and white and official “signoffs” should be procured from clients for everything
Management insists on getting written “signoffs” on all processes and documents from the customer to offset the risk of noncompliance and ungainly negotiations at a later stage. Official signoffs hamper the building of implicit trust between teams and reduce the chances of an evolution of an empirical process over time. This is because the signed off processes end up being considered as the de-facto standard and improvements are not encouraged as they would also need to go through the same signoff cycle. This mentality also reflects in the way the team communicates with each other. Emails float around for simple tasks and no action is taken unless a written receipt is available.
6. The onus of decision-making lies with the seniors in the team
In a typical waterfall project, the team is accustomed to obey orders from the management. The seniors in the team are always in charge of sound decision making and a strict top-down approach is followed. Because of this, the team always feels compelled to adhere to this bureaucratic structure and feel apprehensive about taking any decisions by themselves. Any decisions that they take then always requires formal approval from the management and things do not move forward without it.
7. The developers and testers are two separate entities
Although the skill sets of developers and testers are totally different, both fundamentally contribute towards achieving the team goals. Most teams draw a boundary between developers and testers and the latter are typically not involved in the estimation and prioritization of requirements. They are entrusted the job of testing the work developers deliver and occasionally play the second fiddle in the project. This inherently means that the focus of the testing team is always on finding bugs and not preventing them.
8. Updating the ALM tool is a chore and waste of time
The Agile project management tool or Application lifecycle management (ALM) tool is set up to manage the entire project lifecycle and the team is expected to update the tool regularly to make sure that real-time data is captured and relevant metrics are generated. But, due to the work pressure, the team is not proactive enough to update the tool regularly and intermittent updates hamper the quality of data being captured leading to incorrect insights.
9. Task allocations should be done by some “authority” figure in the team
In a traditional setup, the team tends to wait for work to be allocated to them by Team Leads. Individual team members avoid proactively taking up work out of the fear of being held responsible if something goes wrong. Thus, to play safe, they wait for the seniors in the team to allocate work and all communication related to the requirements happens via this route
10. Requirements should be frozen and signed off before the development starts
Typical waterfall projects have a requirements gathering phase which runs for a considerable amount of time depending upon the complexity of the project. Requirements are written in the form of SRS/FRS/BRD which need to be signed off before the start of the development phase. Writing these documents consumes a lot of time and reading them in detail to sign off is often a herculean task for the project stakeholders. But, contracts are drafted based on the signed off requirements and deviation from this results in scope changes being raised that alter the schedule, scope and budget
These misbeliefs are often ingrained within the team due to traditional setup to which they are accustomed to. Hence, it is not uncommon for projects to implement Scrum, yet deviate from the driving principles of Agile. Quality audits cannot detect these shenanigans as they mostly focus on validating the prescribed practices. This is precisely why an Agile Coach is required – to embody the essence of Agile and drive the Agile transformation strategy. The coach should not shy away from preaching the Agile philosophy much like a spiritual leader whose sermons defy superficial existence and carry a deeper meaning. These discourses may sound too theoretical but their implementation is highly beneficial. The Agile Coach systematically helps teams to put these theoretical concepts into practice.
So by understanding what restricts us to achieve Agile maturity, we can take the right steps to ensure that we do not dismiss Agile as just another market fad. Doing it incorrectly is almost equal to, or even worse than, not doing it at all. Patience, enthusiasm and discipline form the three pillars of Agile adoption and the Coach is the architect who can help teams to achieve agility and accelerate the delivery of sizable business value.