What's wrong with Agile?

1)????? Agile has a snake oil problem

Often, commercialized tools/offerings loom larger than the actual Agile team collaboration. Therefore, project teams that purchase various tools marketed with the Agile tagline (MS Teams - MS Teams Chat and MS Teams Wiki, MS Sharepoint, Slack, Confluence, Jira, Microsoft Azure Power BI Dashboard, and even Miro board) often produce documentation, task artifacts, and status reports that are scattered across different sources of truth (commercialized tools). This top-down Agile tooling enablement initiative, championed by management, ironically usually ends up making collaboration really hard.

Agile consulting businesses capitalize on the wonders created by disruptive innovations to market their effectiveness and a one-size-fits-all transformation remedy. In the end, consulting services earn big bucks, but Agile rarely delights the customers. Agile does create value, but mostly for those who heavily market this Agile silver bullet. The success of Google, Amazon, and Apple can't be solely attributed to Agile Transformation.

?

2)????? Agile has a short-termism problem

The highly repetitive, visual demo oriented short sprint cycles might encourage short-term thinking.

Agile incentivizes individuals and projects to game the system by prioritizing short-term gains (through visual-demo-enabled solutions filled with corner-cutting workarounds; as well as quick success stories and fast-tracked KPI outcomes with skewed data interpretation).

The teams keep on undoing and redoing the works from previous sprints that are not done right as they applied corner-cutting workarounds to please the management during each Sprint Demo ceremony so that management can celebrate quick wins and success stories for quarterly OKRs.

It's not that the managers, SCRUM Masters, or SCRUM team members don't want to be Agile; rather, the excessively frequent two-week iterative delivery windows, coupled with the pressure to meet quarterly OKR objectives, push the entire community to repeatedly adopt corner-cutting, visual-demo-enabled solutions to appease stakeholders eager for rapid ROI. This fosters a perfect environment for embracing short-termism.

3)????? Agile has a fragmentation problem

What is your take on the SCRUM methodology that often slices requirements into fragmented information in the form of individual user stories that span across multiple sprints for the sake of fitting the timeboxed team velocity into short iterative cycles?

Hard problems that require medium to long-term efforts for resolution are often forced to be sliced into fragmented pieces and squeezed into unrealistic short iterative sprint cycles. This is done so that the SCRUM teams are able to impress the VVIPs with their half-baked products/software deliverables during Sprint Review ceremonies at the end of 2-week or 3-week Sprint iterative cycles.

When stories are sliced from user requirements based on a short sprint’s timeboxed perspective rather than the functional and technical composition viewpoint, the documented business requirements become extremely fragmented and hard to understand. Therefore, they no longer form a big picture and holistic view about the actual user demands and business use cases.

?

4)????? Agile has an execution problem

Agile also incentivizes people to organize and attend more meetings (so-called refinements, SCRUM of SCRUM, squad meetings, Guild meetings) without accomplishing anything.

Have you noticed that the time spent on various repetitive SCRUM ceremonies, especially Sprint Review preparation, is substantial? This includes tasks such as PowerPoint preparation, environment and demo data setup, pre-demo dry run (demo rehearsal), and so on. However, many visualized demos are premature, one-time hacks, and completely unnecessary. They are aimed to impress the business executives who happen to attend the Sprint Review demo, rather than delivering actual working software that has undergone rigorous testing and is production-ready.

Despite emphasizing collaboration over documentation, Agile often ends up prioritizing meetings over actions.

?

5)????? Agile has an organization politics problem

Agile organization often separates the roles between people manager and functional manager in the name of avoiding conflict of interest. But ironically, the segregation of the roles that used to be played by a single department or team manager often leads to more politics than collaboration.

For example, the primary reason for the frequent failure of the Spotify model, which separates the roles of people manager (Chapter Lead) and functional manager (Product Owner, Technical Lead), is the misalignment of incentives between these two reporting lines. Rarely do the incentives of both roles align. The functional manager, whose key performance indicators (KPIs) depend on your project and functional duty productivity, often lacks the incentive to support your exploration, experimentation, and growth in areas that genuinely interest you but do not directly benefit them..

On the other hand, your people manager, who may have limited visibility and stake in your projects, often struggles to understand what it takes to maximize your project productivity and happiness or to help you navigate challenging situations within the project. This is because your functional manager is typically hesitant to involve your people manager, preventing them from gaining visibility and having a stake in your work. Lastly, your people manager, who needs to manage their own functional portfolio and project throughput, faces a different set of challenges and is likely unable to provide sustained support for their direct reports.

6)????? Agile often add chaos to the unknowns

In theory, the Agile framework should empower everyone to clarify things in situations characterized by ambiguity, uncertainty, and widespread confusion. It must not tolerate a group of opportunists and ambitious individuals attempting to outsmart others by opportunistically intervening in various decision-making discussions, thus adding chaos to the unknowns.

The above point is the primary reason why I hold disdain and aversion towards Agile Framework and Agile Transformation. Agile often introduces chaos into the unknowns, with a slew of opportunists vying for power, contending by convening meetings and dominating meeting agendas to achieve their power-grabbing objectives.

7)????? Agile — Is it a silver bullet?

In fact, Agile Practices are not silver bullets. If your business model is wrong, no SCRUM processes, digitalization and automation will be able to save your day. But if your goal is to expose your weaknesses and make them transparent, the highly frequent SCRUM review and retrospective ceremonies will make your vulnerabilities clear.

Agile Manifesto and Agile Transformation are the narrative of programmer-centric communities to take over the world. Therefore, testers will never be emphasized and being held with high regard in the Agile resource planning.

The ambiguous and mysterious nature of Agile guidelines/practices make Agile Coaching and Agile Consulting a highly profitable business. Because no one is doing Agile right and many more have failed miserably to harness tangible benefits and ROI from Agile processes and yet feeling guilty for not leveraging Agile processes to turn around their businesses and operations, this FOMO syndrome opens up opportunities for Agile Coaches and Consultants to sell them expensive services, and enabling softwares, Agile crash courses, professional certified examinations and etc to realize Agile Transformation.

?

8)????? What is the key takeaway from this article critiquing the hype around Agile?

Every software development process model and methodology has biases. Agile is in favor of programmers, offering the greatest autonomy and flexibility in work arrangements with less external influence, supported by a SCRUM master who acts as a shield against external stakeholders' pressure and interference. The V-model is favored by business analysts, as it provides rigorous validation of business requirements and verification of technical solution implementation using a requirement traceability matrix. Waterfall is in favor of project managers, emphasizing meticulous and organized tracking, monitoring, and reporting of resources, costs, and project task breakdowns. All these methodologies are options in our toolbox, serving as enabling tools and processes. None of them should be positioned as a one-size-fits-all silver bullet or game-changer. The real game-changers are the business model, talent, and innovative technology solutions.

The goal of any software development process model is not to nurture purists who only see, interpret, and respond to the world through their lens and insist on changing the world using their purist worldview, but to establish expert networks that are collaborative and accountable for their actions, inactions, decisions, and indecisions.

Any process model or methodology that deviates from the goals of quick flow of information, empowerment, informed decision-making, and efficient action is not worth pursuing.

#agilemethodologies #agilemethodology #agile #scrum