Originally published April 17, 2018 @ 10:56 pm
State of Agile” report. The survey involved more than 1,400 software professionals in various roles and industries over the fourth quarter of 2017.
Only 12% responded that their organizations have a high level of competency with agile practices across the organization, and only 4% report that agile practices are enabling greater adaptability to market conditions… The three most significant challenges to agile adoption and scaling are reported as organizational culture at odds with agile values (53%), general organizational resistance to change (46%), and inadequate management support and sponsorship (42%)…1
Resistance to change is normal and a sign of active engagement.
Resistance to new ideas is very natural. The behavior shows that an individual is actively engaged in evaluating the new possibilities against his or her past experiences. 2
It’s not “resistance to change” just because your idea is not readily accepted.
Traditionally, resistance is defined where change implementers perceive a difficulty in having their ideas accepted… 3
When half of the organization rejects a particular change, a review of the proposal for elements of latent stupidity may be in order prior to crying “resistance to change”.
It is also entirely possible that, viewing opposition to your proposal through a prism of your hurt feelings, you are seeing “resistance to change” where genuine and constructive criticism is being offered. Not everything is a conspiracy: a roadblock may be there simply so that you don’t hurt yourself.
An even greater challenge to the agile development concept is posed by company culture, according to VersionOne’s survey. Employees may not be resisting change because they don’t think it’s a good idea. They may simply understand from experience that the proposed change is not a good idea here and now; that certain aspects of organizational culture need to change before the new idea has a chance to succeed; that putting the cart before the horse is at best a waste of a perfectly good horse.
Reading the twelve principles set forth in the The Manifesto for Agile Software Development, two things immediately become apparent 4:
-
The Agile concept was designed for software engineering. It’s effectiveness or even advisability in other fields of IT is not being discussed. Conveyor belt assembly works brilliantly in the automotive industry. Will it work just as well in psychiatry?
-
The authors’ assertions are not supported by research outside their personal work experience. Hence the name “Manifesto”. It’s a noisy proclamation by a group of disgruntled programmers – however brilliant – seeking to take a shortcut to public acceptance of their point of view.
An often overlooked background for The Manifesto: the concepts it presents were formulated for the business of writing software; for companies that develop software as their end product and not just a means to an end. Selling software as a product and selling a product powered by software in the background are two substantially different business models.
Equating in status external and internal customers, of course, is only acceptable when talking to internal customers. After all, you will never tell a paying external client that his project is being delayed because your other “customer” – Bob from accounting – is waiting for a patch for the spreadsheet macro.
Perhaps the weakest point of The Manifesto is the absurd idea of self-organizing teams. The very term “self-organizing” is an oxymoron. The ultimate and most pervasive law of nature is entropy. Disorder grows and brilliant ideas dissolve into background radiation if nobody directs the creative process. Alternatively, you must accept that the organization’s resistance to your proposed change is one possible outcome of this self-organizing process.
None of these objections seem to matter: due to too many unclear definitions, the Agile concept long-ago has been hijacked by managers and consultants using it to drive personal agendas. Agile has become a synonym for “good”. When you say “we need to be Agile“, you’re saying “we need to do the right thing”. Who would argue with that? In many cases, agile is simply used to institutionalize the usual lack of planning and testing.
Naturally, VersionOne’s report puts an optimistic spin on the state of Agile by claiming a positive trend in corporate acceptance of the concept. This is great, maybe, but here’s something to keep in mind: this is a 12th annual report. And in reality the Agile concept is even older:
Created in 2001, Agile is a rapid development process used by a cross-functional team that ideally works together closely and meets daily. 5
Let me put this in perspective: the Agile idea appeared before C#, PowerShell, or Go. The top song was All For You by Janet Jackson. The first Shrek came out. In computer years, 2001 is antiquity. If a new concept in IT did not gain wide acceptance after seventeen years – it never will.
Update: “Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon “Agile”.6
“…doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”.” 7
[7] “Developers Should Abandon Agile.” What Is Extreme Programming?, ronjeffries.com/articles/018-01ff/abandon-1/.
Experienced Unix/Linux System Administrator with 20-year background in Systems Analysis, Problem Resolution and Engineering Application Support in a large distributed Unix and Windows server environment. Strong problem determination skills. Good knowledge of networking, remote diagnostic techniques, firewalls and network security. Extensive experience with engineering application and database servers, high-availability systems, high-performance computing clusters, and process automation.
