A former Google software engineer and architect, in a book on software quality, states that Agile methodology can often become a tool for micro-management and result in poor code.

Murat Guler is a software engineer and architect, worked at Google for more than 13 years and before that, Qualcomm. He has now founded a startup building a web application to assist companies with software engineering technical interviews.

He resigned from Google in September 2022, and has since written a book, Defending Software Quality, promising “honest critiques and actionable suggestions”, according to his post on LinkedIn.

Guler has posted a chapter on Agile as a Micromanagement Tool which challenges the assumption that adoption of Agile methodology improves productivity and code quality. Agile is more than mature, with the original Agile Manifesto now 23 years old. It was in part a reaction to the weaknesses of “waterfall” development, where a team gathers requirements, creates a specification, and then builds the software – though note that this may be a mis-representation of actual Waterfall methodology. Agile favours an incremental approach, starting with a minimum viable product and gradually adding features based on user feedback.

The author, who emphasized that he is not describing any specific company, outlines anecdotal evidence from “friends and various engineers … from various different companies” suggesting Agile is “being used as a micromanagement tool.”

The core issue, Guler says, is the principle of Agile that states that “business people and developers must work together daily throughout the project” – this is taken from the Agile Manifesto. This can easily encourage micromanagement, he says, where the product owners “dominate the discussions and override the opinions of the engineers.” Estimates of how long work will take become deadlines and engineers feel untrusted, scrutinized, and negatively criticized when things do not go well.

The situation can then worsen, with managers implementing new processes including “long and very detailed requirements documents” that become an additional burden, further reducing productivity. Feature flags, a way of enabling and disabling features, may be introduced to improve reliability, but “too many flags mean there are too many combinations,” Guler writes, so that proper testing is difficult.

These are examples of Agile gone wrong, but according to Guler there are other issues even when the methodology is used correctly. The notion of 2-week “sprints” where a set of features is developed might not fit all types of software development. “Welcoming changing requirements,” another Agile principle, might become a problem if those on the business side “arbitrarily change requirements too late into the development cycle.” He also questions the notion of not beginning with requirements documentation, stating that “a good design document is a valuable part of the software development process.”

Pair programming, where two developers sit together and work on the same code, is a “brand of torture” and “highly distracting,” Guler says. And shared code ownership is “another terrible idea from Agile philosophy” since it can result in poorly maintained code because “everyone thought someone else could take care of it.”

The post has attracted support from other developers who feel they have suffered from the imposition of Agile methodology. “My work is infested with agile and safe coaches. They know nothing about the business or anything technical. It’s a zero value add position that makes the IT budget bloated. Would be nice to get rid of all of them and hire more people that actually do work,” remarked one such on Reddit.

Another common reflection is that Agile can be “kind of culty”, picking up on Guler’s remark that Agile “has become somewhat of a religion,” with priests (Agile coaches), daily prayers and confessions.

Another core Agile principle though is valuing “individuals and interactions over processes and tools” and what Guler’s analysis demonstrates is that if the team dynamics, communication, and mutual trust is wrong, no amount of process will fix it.