Impediments to smooth Agile adoption
20 September 2016
Volatile market dynamics and the desire to adapt to ever-changing customer needs have increased Agile awareness. Businesses have understood the benefits of Agile and are proactively willing to jump on the Agile bandwagon. Market research has shown that the majority of teams start their Agile journey by way of Scrum.
But more often than not, the decision to adopt Scrum — or any Agile method, for that matter — is driven by inadequate knowledge of the core principles of Agile. People start their journey with full enthusiasm, only to realize later that things are not working out as expected. As a result, many teams revert to their old way of working and claim that Agile is not suitable in their context. In this article, we discuss some of the delusions that hamper smooth Agile adoption.
Ideological delusions that hamper Agile adoption
Reading about Scrum and following the ceremonies is enough
Many teams take this route when 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 as just another way of working. Reading about Scrum usually tells them only about the prescribed practices, not about the rationale behind them.
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, 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 expected to streamline deliveries right from Sprint 1. Fast, seamless, and error-free deliveries require careful strategizing, expert execution, and patience.
We can do away with documentation
Agile advocates the reduction of waste by shying away from unnecessary documentation. But architecture documents, project plans, and strategy documents, which form the basis of future project activities, cannot be omitted. Thus, the most important documentation has to be identified and maintained for any project. Documents that add no specific value to the project need to be identified and done away with.
A project manager can be the ScrumMaster
Owing to the way projects are set up and billed, many teams are reluctant to hire a full-time ScrumMaster. Popular beliefs dictate that project managers can be ScrumMasters. Traditional project managers go along with their business as usual, and ScrumMasters just end up being a designation on paper. The specific responsibilities of a ScrumMaster are fulfilled to some extent, but the concept of servant leadership never materializes.
All communication among teams should be in black and white
Management insists on getting written sign-offs on all processes and documents from the customer to offset the risk of noncompliance and ungainly negotiations at a later stage. Official sign-offs hamper the building of implicit trust among teams and reduce the chances of evolving the empirical process over time because the signed-off processes are considered the de facto standard. Improvements are not encouraged, as they would also need to go through the same sign-off cycle. This mentality is also reflected in the way teams communicate with each other. Emails float around for simple tasks, and no action is taken unless a written receipt is available.
The onus of decision making is on the team's seniors
In a typical Waterfall project, the team is accustomed to obeying orders from management. The seniors on the team are always in charge of sound decision making, and a strict top-down approach is followed. As a result, the team feels compelled to adhere to this bureaucratic structure and feels apprehensive about making any decisions by themselves. Any decisions that they make require formal approval from management; nothing moves forward without it.
Developers and testers are on two separate teams
Although the skill sets of developers and testers are totally different, both fundamentally contribute toward 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 that developers deliver, and they often play second fiddle in the project. This inherently means that the focus of the testing team is always on finding bugs, not preventing them.
Updating the ALM tool is a chore and waste of time
The application life cycle management tool is set up to manage the entire project life cycle, 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 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.
The team's authority figure should perform task allocations
In a traditional setup, the team tends to wait for team leads to allocate work to them. Individual team members avoid proactively taking work out of the fear of being held responsible if something goes wrong. Thus, to play it safe, they wait for the seniors on the team to allocate work, and all communication related to the requirements happens via this route.
Freeze and sign-off on requirements before development starts
Typical Waterfall projects have a requirements-gathering phase that runs for a considerable amount of time, depending upon the complexity of the project. Requirements are written in the form of software requirement specifications, functional requirements specifications, and business requirement documents, which need to be signed off before starting 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 raising scope changes that alter the schedule, scope, and budget.
Embodying the essence of Agile
These misbeliefs are often ingrained within the team due to the traditional setup to which they were accustomed. Therefore, it is not uncommon for projects to implement Scrum and 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. The coach should not shy away from preaching the Agile philosophy, much as a spiritual leader's sermons may 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 put these theoretical concepts into practice.
So by understanding what restricts us from achieving 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 equal to, or 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 achieve agility and accelerate the delivery of sizable business value.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.5 (2 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.