There’s something I started to notice around 2011, but didn’t quite understand until recently. Now I think I have a handle on it.
From time to time I hear agile coaches describe a particular client company as a place where agile thinking never penetrates, or where agile methods are never properly adopted. It seems as if most of the larger markets have at least one such company or governmental organization.
One (that I know of) is known in its local market as “the place where agile goes to die.” Coaches in other markets have been less poetical in their descriptions, but many of them are aware of at least one client company that has a similar local reputation.
After most of the local coaches have done their time at the company, they won’t return. They tell their friends. The company gains a reputation as a bad place for an agile coach to go. The company has to pay for road warriors to come in from elsewhere to help them.
I’ve worked in, visited, or spoken with personnel at several companies that have this sort of reputation among local agile coaches. I think I finally see the pattern (although I could be mistaken).
Here’s the part I expect people to dislike: The problem isn’t the organizations, it’s the coaches.
About the organizations
The companies/organizations in this category that I’ve interacted with are in different industries (financial, telecom, retail, government) and different markets (San Francisco, Los Angeles, Dallas, Washington DC). They have two characteristics in common:
- they were established many years ago and have deeply entrenched Industrial Era structures, mindsets, and procedures as well as legacy systems of significant age and scope; and
- they are relatively large – 20,000+ employees and contractors on staff.
About my experiences
What I’ve learned by working in, visiting, and speaking with people in these organizations is that they are serious about improvement, but can’t readily or quickly change the way everyone thinks and works. They steadily make improvements in their processes and practices, but progress is slow and there is always a mix of old and new methods, old and new thinking. Sometimes they “backslide” and try again later, moving ahead a bit further than they had done in their previous attempts.
A few years ago, I told my colleagues I was going to start a coaching engagement at a company that had this sort of reputation in the local market. They laughed, made the sign of the cross as if warding off vampires, and started to place bets about how long I would last there. The bets were in the range of weeks. Ultimately I worked with that client for two years, in two of their locations, only leaving because they have a two-year limitation on external contractors. It turned out to be one of the most rewarding, if not the single most rewarding engagement of my career to date.
So, why the bad reputation?
About the coaches
My observation is there are a couple of broad categories of agile practitioners, including coaches. This is only a personal view, of course.
The first category comprises individuals who had a fair bit of professional experience in the IT industry at the time “agile” started to become popular, including the people who coined the term and wrote the Agile Manifesto, as well as other professionals of that era. Their understanding of “agile” comes from the challenges they faced in the trenches of software development, delivery, and support in large organizations such as corporate IT departments.
The second category comprises individuals who learned about “agile” after it had become a Thing. They read about it in books…and when something is in a book, it sometimes assumes magical properties.
With the usual risk inherent in making generalizations, I’ll observe that people in the first category tend to apply agile thinking pragmatically. They want to solve problems, and they have learned that many of the principles and methods associated with the popular buzzword are very good for solving the kinds of problems software developers face. Many of them have learned to apply the same principles to other areas of work and life, as well. They also understand how to adapt agile principles and methods according to context, to achieve specific goals.
Agile is all about results.
I’ll risk another generalization and suggest that people in the second category tend to think of “agile” as a kind of quasi-religious thing. Many of them have earned a credential such as Certified Scrum Master (CSM) or Scaled Agile Framework Certification (SPC), but haven’t actually worked as programmers, software testers, analysts, architects, database administrators, or project managers; or in production support or operations roles in IT. They may think of “agile” as a Good Thing To Do, and they may have a pretty good academic idea of why it helps, but they lack a visceral or gut-level sense of why and how agile principles actually work in context, or (and this is the key part) when to relax them.
Agile is all about rules.
Because of the very different ways each group was introduced to “agile,” their expectations are very different.
The first group are looking for improvement wherever they can find it. Process improvements using agile, lean, systems thinking, theory of constraints, complexity theory, queuing theory, or keep-trying-things-until-something-works are all acceptable to them. Improvements in the quality of working life for software professionals are welcome in whatever form they can be achieved. When an organization they’re helping manages to make today just a little bit better than yesterday, that’s a “win” and they’re happy.
The second group are looking for a theoretically-perfect expression of “agile” as it is described in the literature.
They’ve read that feature teams are more effective than component teams. In many large organizations, it isn’t feasible to arrange things that way across the board, for a thousand and one reasons. The coaches become frustrated.
They’ve read that a production-ready solution increment has to be produced every two weeks. In many large organizations, that sort of delivery performance lies at the end of a very long road indeed. The coaches become frustrated.
They’ve read that humans are to be treated as humans and not as “resources;” that teams ought to be collocated, stable, and dedicated; that teams have to be small and yet include all the skills necessary to deliver end-to-end functionality. Then they find out what “end-to-end” really means in a large enterprise IT environment, how many disparate technologies are in play, and how many people it takes to provide all the skills necessary. The coaches become frustrated.
The list goes on. They’ve read This and they’ve read That, and larger organizations with a long history may not be able to adhere to all of it; at least, not in the short term, and not without very considerable effort. The coaches become frustrated…
…and the organization gains a reputation as “the place where agile goes to die.”
Only it isn’t. It’s the place where agile is hard. For that very reason, it’s the place where progress is the most rewarding.