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.
About expectations
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.
Don’t know I agree with the types of coaches (haven’t met enough yet) but agree 100% that it’s not about agile. It’s about business results and improvements in people’s lives. An agile / lean / etc approach is a tool box that is applied in different ways as a result of different contexts. And sometimes a “win” is when you make progress and head things in the right direction. It is not always a destination.
Great post. The same can be said in other “process centric” domain. One here is Earned Value Management or Programmatic and Technical Risk Management. Just replace Agile with those terms and you’d see the same behaviors
Great post David. I do think (like most humans) that we tend to think in the short term. COaches are no different; one must be patient when working with Behemoth Bureaucracies. The do want to change, but the system is slow to change… And in actuality you want that… Every little improvement made is a change in culture for the organization. Large scale culture changes usually have problems even if ultimately the organization comes out OK on the other side. Look no further than cultural anthropology to get a sense of this. As long as people want to make improvement, and preferably involve others around them, I’m in.
Cheers,
Paul
My apologies, but I have a hard time seeing this post as something other than a humblebrag.
I sat in a jungle lost in a book,
suddenly I hazarded a look,
I found myself between two lions,
moral, don’t always read between the lions….
You must read the message, there is much to mull over…
Really great post. I would suggest besides Agilists who are focused on results, and Agilists that are focused on rules the early camp of Agilists had a lot of folks who were focused on being. At the team level this is not much of a problem but for an organization this can be a serious challenge because it ignores system thinking. Wondering what your thoughts are.
Well, I think the idea of “being agile” comes down to mindset, and there’s nothing to prevent people including systems thinking (and other disciplines) in their mindset. With that in mind, I’m not sure it’s a problem.
definitely can have an Agile mindset with or without systems thinking. Suggesting that an Agile mindset without systems thinking makes it very difficult to do Agile beyond a team or so.
Definitely agree. And systems thinking without an agile mindset at the outset may well lead to (among other things) an agile mindset.
I think some introduction to systems thinking should be part of elementary education, isn’t it? so we have to change that system.
But what exactly is “being agile”? or “having an Agile mindset?” …
I like to keep things well defined and stick to the 12 Principles and 4 Value comparisons of the Manifesto.
Unfortunately objective measurement of many companies claiming to “be agile” so very low scores when measured this way….
IMO “having an agile mindset” means thinking in a way consistent with the 4 values. It doesn’t seem mysterious or complicated to me.
@Dave – NOT 4 values, but 8 – arranged in comparative pairs… Remember: “That is, while there is value in the items on the right, we value the items on the left more.”..
So if someone disregards the 12 principles, but manages to achieve healthy values, would claim they are “being Agile”??? [I would not]
Sure, I can see that. Four statements that mention eight things. Fine. As the principles are illustrations of the values, I think it’s not possible to “disregard” them.
Now we’re diverging pretty far from the point of the post, and I prefer not to get into a debate about when or why a person would “claim” to be agile. Cheers!
Fair enough, it is your blog; so this will be my last comment on the subject…. If one does not define Agile clearly, how can one know if it has gone somewhere in the first place, or if it has died; let alone even think about why….
Cheers!
Thank you for your comments. I’m glad to see that others feel the same way. Maybe one day… who knows? Wer weiss, wer we3i0Rss;? (from Vor meinem Vaterhaus)
Thanks. Really helped me gain some perspective. Been struggling with related feelings for a few years.
Suggest that the title of this post should have been “The problem isn’t the organizations, it’s the coaches”. Lead with the controversy.
Saying that the problem is in the coaches is a simplification, it’s about people in general. In an organisation I know agile is incredibly hard and many coaches burnt themselves mainly because it was the management that heard/read about agile and started expecting it to work like any other documented process, ideally from day one of being implemented. Exactly like you describe, demanding that the entire IT, regardless of the context, starts working in 2-week sprints, from day to day changing composition of the teams because they shouldn’t be bigger than, should consist of etc. So I do still think that there are organisations where it’s not the coaches fault and I am full of admiration for all the excellent coaches who struggle having no support from the transformation programs and higher management, but still try to make life in the trenches better, regardless of when they became introduced to agile.
Yes, I think trying to make life in a trenches better is a good goal, and more achievable that a stem-to-stern organizational transformation.
Hi Dave
Nice article. I’ve found the difficult case to be the ones where most learning occurs. The ones where you have to extend your toolkit.
I’ve seen something similar. I’m not sure if its when people join the Agile train. This was my attempt to articulate… https://theitriskmanager.wordpress.com/2015/04/19/communities-of-need-community-of-solutions/
Chris
I agree with your splitting the landscape between “all about results” and “all about rules”, and with your conclusion that this leads to ineffective transformations, frustrated coaches, and maligned organizations.
You seem to be implying, however, that the only ones that fall in the first camp are those old enough to have been part of the original “pioneers” group and/or already experienced practitioners at that time; those who came after “agile became a thing” (early 2000s I suppose), fall into the other category. Consequently, there was a “cut off” date to become an effective agile coach. I was wondering if that’s actually the message you wanted to convey. I have the feeling (the hope?) that this wasn’t your intent, but just wanted to point out that my first pass reading led me in that direction.
Well, it’s a generalization, so it’s bound to be wrong in specific cases.
Very insightful. I see these two clusters all the time. There will always be edge cases … I know some newly-minted agile coaches who get it and work pragmatically, and old war-horses who want to follow simple heuristics as rigid rules … but I am always bemused and amused by the zealotry and arrogance from some coaches that an organisation will never become agile when they stumble at the first hurdle and feel the pain when the lumbering beast tries to swat the fly away. My most memorable and enjoyable engagements have been with larger organisations, but rarely as an external consultant do we get to work with an organisation for longer than three months. That’s why I have now moved out of consultancy and into a large fintech company (more than 20,000 people) to lead their agile transformation as an enterprise agile coach. I am looking forward to the next few years.
Best of luck with your new position!
Some really great points, alas, it would require an equally long response to cover my reaction to all of them.
1) I agree about the distinction between those who have lived through it vs. those who have only “book” learning. Until one experiences the pain of the “old ways” (in my case Gastric bleeding from ulcerations back in the late 1980s) it is very difficult to truly appreciate all of the aspects.
2) I disagree that is it *ALL* about the “coach”. There are some teams where there could be a benefit to a transformation but there is one or more (somethimes localized) blocker. An extreme case of this was a NY based company who had an employee who has such sway that he was able to force all of the computers to be set to Bogota Time [rather than Eastern US] because is batch files for source control would not handle the reversal of time (daylight savings in the fall) and he had lost work one year. Until he retired, the company did things “his way” regardless of any other considerations.
(more to come, but I’ll leave it there for now)
David, sorry to hear about the health issues arising from 1980s style work. So many stories like that, unfortunately.
Regarding point 2, bear in mind the subject of the post is not the effectiveness of the coach’s work or the ability of the organization to improve, but rather the mindset on the part of some coaches that certain organizations are irredeemable.
As you said in another reply “Well, it’s a generalization, so it’s bound to be wrong in specific cases.”…. 99.9% “hard”, 0.1% irredeemable [arbitrary numbers]…
Well said. I’m out there saying the same thing (less courteously) all over the place.
I am not sure it has to do with origins exactly. But I do perceive those two mindsets as opposite visions colliding in the mindspace of agility, and I agree that correcting it is itself important and hard.
The coaches you describe have not succeeded, because they only practice agile “by the book.” Agile principles can be applied to make any company more efficient. Agile is more a tool set and a mind set. Coaching should be about listening and adapting.