How Agile became a mis-Agile Disaster

andvgal1 pts0 comments

How Agile became a mis-Agile Disaster | by Andrey Galkin | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

How Agile became a mis-Agile Disaster

Andrey Galkin

5 min read·<br>Just now

Listen

Share

Back in the end of the 90’s and start of the 00’s, Agile was an approach to cut corners for highly professional activities to improve development performance and delivery times without sacrificing quality. Somehow, the true Agile bias of the manifesto and the principles turned into dogmas of complete rejection of less favorable values. Let’s call it mis-Agile.<br>Mis-Agile’s main problem used to be and remains project continuity upon staff rotation, including up- and down-scaling. Therefore, even in the early 10’s, large US corporations were not accepting pure Agile as a replacement for project and program management. Advocating for a shift to Agile-only was considered immature and amateurish for professional application. Then something had changed. Certain books and research papers were not the cause, but the consequence of the shift towards flat teal swarms with caveman-level skill sets.<br>Factor: rise of outsourcing companies<br>With no surprise, the world’s leading outsourcing companies have been evangelizing mis-Agile in the first place, also pushing the agenda through universities. The cause is pure business interest. The service can typically be billed either based on an hourly rate or based on the delivery of the project or its milestones. In the former case, outsourcing companies are interested in more hours billed, while in the latter case, they are interested in evading legal accountability by eliminating clarity in statements of work. If pure Agile is so efficient, then it’s like shooting oneself in the foot to cut one’s revenue by decreasing man-hours billed.<br>Factor: the IT boom<br>There was a rapid rise in demand for IT workers in the late 10’s and early 20’s, which caused masses to pursue appealing salaries by storming both university-level and suspicious-level of educational facilities. Unavoidably, the average level of competence has declined over previous periods. Outsourcing companies were the primary “consumers” of new graduates and even pre-graduates.<br>However, the main problem was the lack of a sufficient number of competent development managers to handle swarms of juniors and company communication to customers. Promoting unfit team members to managers could not solve the problem. Flat Agile-themed teams of often junior-only team members with little to no role models of engineering excellence were the natural workaround. Original Agile was assuming highly competent specialists instead.<br>Factor: corporate evasion of accountability<br>Top managers tend to create some mid-management subordinates as a buffer for failures to protect their own bases, while keeping direct heavy influence on teams. Mis-Agile methodologies have provided a wonderful excuse for blaming empowered self-organized teams for all project-related issues. There is less need for expendable middle management. In reality, empowered teams are a psychological illusion, while flat anarchical swarms can create natural hot tensions in teams in practice.<br>However, such an anti-management structure requires justification. With no surprise, supporting books and research results appeared just when needed. On the other hand, that even contradicts the natural structure in swarms of bees, ants, termites, and other species with strict roles and hierarchy inside colonies.<br>Stock corporations and startups targeting IPO are not about their own economics or efficiency, unlike many standalone private capital companies. Without expanding the topic, they are quite different types of entities in a much larger picture, and such a state of affairs can easily take place, therefore.<br>Personal experience<br>In 2006, author started professional career with an excellent manager, Uldis Briedis, who established a variation of eXtreme Programming (XP) practices on tactical level in a team of 10–20 developers, while it was backed by corporate Software Development Life Cycle (SDLC) as a variation of Rational Unified Process (RUP) with proper product requirements management and Quality Assurance in place on strategical level. That was an absolute winning combination back then and remains so nowadays.<br>By 2012, some program management had already shifted towards discrete Scrum sprints and late decision on code integration, which had already been in some conflict with XP ideology of natural performance flow. Meanwhile, top management was sticking to a firm SDLC, supporting bandwidth releasing of at least two separate projects every week, 100+ projects per year.<br>In around 2013, that led to an interesting conversation with Jim Brodie during an annual meetup at headquarters, who demolished Scrum “fan boys”, including the author, with a simple question of what exact problem Scrum was supposed to solve [in the company’s ways of...

agile management level companies teams problem

Related Articles