Agile is one of the most popular approaches in the software development world, but more often than not, it is also the least commonly understood.
According to Forrester, business agility is the quality that allows an enterprise to embrace market and operational changes as a matter of routine. Forrester views agility as a way of thinking that requires both awareness and execution.
The need for business agility drives engineering agility. While agile has spread as businesses demand more flexibility and responsiveness from IT systems, it has also become a huge economic powerhouse. It is a massive industrial complex—the frameworks, tools, certifications, coaches, consultants, trainers, service providers, and more around which millions globally make their living. Yet, many times, because of these very forces, the focus of agile software development shifts away from where it should be, affecting customers and the engineering teams.
This shift in focus can push organizations through the dark tunnels of cookie-cutter agile frameworks, methodologies, coaches, and certifications. At the start of the agile adoption journey, rituals and ceremonies provide a cadence and a feel-good factor. However, without a focus on genuine software engineering, programming excellence, and creating technology solutions based on customer need, teams drown in a sometimes meaningless process of simply going through the motions.
A quick look at the Agile Manifesto reminds us that adopting agile should never be about blindly following prescribedframeworks, methodologies, and tools, and it’s certainly not about courses and certifications. The focus must be on following the agile principles that guide technical excellence.
Agile should be about using tailored practices, techniques, tools, and team organizations that fully align to a customer’s business context. But the drivers of the cookie-cutter world strongly influence businesses and their IT teams to follow their one-size-fits-all frameworks, methods, and tools. Such an approach often introduces many risks, so beware of the following symptoms that may indicate that your agile team has gone astray.
Lack of Project Management
Agile is about people centricity in an environment that is committed to software quality, team productivity, and continuous improvement. While teams are encouraged to be self-organized, it does not mean that projects do not require some level of project management.
Some vendor frameworks and methods leave the impression that a role as critical as a project manager is not required; they only advocate a servant leader role. Likewise, these vendor frameworks leave an impression that team structures must conform to what they prescribe. This, more often than not, leads to suboptimally leveraging individuals’ and team’s capacity and capability.
Experience in projects and programs has shown that a lot of care and attention is required in shaping teams that are aligned to a context, including in an outsourced scenario.
Misuse of Certification
The reliance on agile certifications often lowers the quality standards of agile software development. Two-day training and certification workshops have mushroomed, but most of the methods they teach do not factor into the realities of the practitioner world. It has resulted in a plethora of “training schools” and “certified folks” floating in the market who do not have the experience and academic credentials to perform the required duties to foster technical and business agility.
Tools Aligned with Prescriptive Frameworks
A symbiotic relationship exists between cookie-cutter agile frameworks and vendors of agile products and tools. The tight binding in the product and tool features with an associated framework does not easily lend itself to ease of customization when an agile-based delivery framework is tailored for a project, program, or an enterprise.
Such occurrences are common, especially in outsourced and offshored engagements. Usage of the tool quickly tapers, and effective adoption of agile engineering practices takes a beating. Enterprises may also be forced to invest in custom tools to make the rigid, uniform frameworks and tools come close to meeting their business needs.
Poor Agile Governance
The scenario above becomes even more chaotic and painful when outsourcers are onboarded to deliver projects or programs using their own, proprietary agile-based methodology. In many cases, outsourcing contracts drafted by vendor management teams are structured with an anti-agile governance mindset. The verbiage and spirit in outsource contracts still remain tightly aligned to the controls and checks and balances of a traditional software methodology, such as waterfall. The principles and values of agile software development do not find a place in such contracts.
Blind adherence to a particular agile approach is fraught with risk and provides no way for teams to self-manage their work. Such contracts and governance greatly contribute to stifling the spirit of agile. It has a direct negative impact on business agility and engineering agility—the very fulcrum on which agile software development rests.
Be Vigilant for These Warning Signs
You first should be mindful and responsible in deciding whether agile software development is applicable and beneficial in your context, be it a project, a program, or an enterprisewide initiative. Then develop tailored ways of workingfor successfully embracing such a change.
In order to make agile work, you must stay on high alert, reason logically when anti-agile patterns raise their ugly head, and take purposeful decisions and actions that make sense for your business.
About the author
Anil Rao is a Senior Vice President at Mindtree. He contributes towards strengthening Mindtree’s software engineering practices and in developing project management, program management and delivery management capabilities. His email address is [email protected].
User Comments
Anil, you have exposed the actual problematic scenarios faced by delivery teams!
In my experience too, I have come across cookie-cutter Agile frameworks being force-fit within enterprises. Most of these initiatives may fall apart, too soon, as they lack a strong foundation upon which their delivery approach (and internally their working principles) are based upon.
The second aspect that caught my attention was the blending of software engineering processes with Agile delivery. I completely agree that these two have to go hand-in-hand to enhance the overall delivery efficiency.
The third aspect is on the Project Management. There is still a lot of confusion out there on the roles (& responsibilities) of a Project Manager and how it plays out with a Servant Leader.
Like what you have mentioned, it is very important that these frameworks be tailored to suit the needs of enterprises rather than a cookie-cutter implementation.
Very good article that expose the weakness of agile methodology (especially frameworks) and helps in strengthening the process that are relevant for the specific business requirement.