A phenomenon that often pops up in software development teams, and one that seems to be a major cause of underperformance, is the Lonesome Cowboy Reflex (LCR). It’s not hard to recognize, however, if you know what to look for, and there are ways of alleviating the issue.
What is the Lonesome Cowboy Reflex?
Consider the following scenario from a daily standup:
John: I’ve been working on story X and hope to finish it today.
Scrum master: Okay, but you’ve been saying this for the past two days. Can somebody else give you a hand to finish it sooner?
John: Pfff… nah. I pretty much know what still needs to happen and I’m working on that codebase now, so a new pair of hand would just slow me down even more. Don’t worry, I’ll tackle it today.
Scrum master: Okay, well, just let us know if we can give a hand.
John: Will do.
Sounds familiar?
This happens time and time again in a lot of software teams. John just exhibited what we’ll call the Lonesome Cowboy Reflex: he’s set on traveling the road for story X alone and does not want a helping hand.
What Happens if You Just Ignore LCR?
Suppose you have a cross-functional team working in a two-week sprint, consisting of a tester, a scrum master, a development lead and five other developers. If you apply the scenario above, you would probably end up with five stories being worked on simultaneously, one by each developer.
Here are some things that are pretty much bound to happen:
The scrum master will be hearing “still working on that” a lot, but at the same time getting the signal that nothing can be done about it. Chances are he’ll start feeling like the personal manservant of each individual developer.
The lead developer will continuously have to divide his effort and attention between five different stories and solutions, being involved with all five at the same time. Depending on what his role entails exactly (code reviewing for example) he will be stretched pretty thin.
The tester, on the other hand, will most likely be twiddling his thumbs until the end of the sprint, at which point five stories are suddenly ready for testing and he has to rush to get his work done. Probably not great for his stress levels.
Your own team setup and roles might vary, but you get the gist of it. This scenario is the exact opposite of what agile methodologies like SCRUM and Kanban aim for… and yet it happens all too frequently in supposedly agile teams.
With the Lonesome Cowboy Reflex, you don’t have a single team working towards a series of goals, but a series of individuals each working towards their own, single goal. Forces are spread too thin, uncertainty about delivery grows, and everything is dependent on individual effort. Lack of team responsibility, lots of room for “not my problem” behavior and an unfair division of individual pressure. All this pretty much defeats the entire purpose of building a team.
Not tackling the Lonesome Cowboy Reflex can result in nobody caring about “the team results” any longer.
What Causes LCR?
The most heard explanation for LCR is that it’s impossible to work together on the same story. “There’s no point really, we’d just get in each other’s way.”
That is simply not true.
When it comes to collaborating in software engineering, there’s a plethora of tools to facilitate it. And good software architecture makes it perfectly possible to work in different areas of the software, but on the same stories.
So the argument really comes down to not having given any serious thought to how it could be done. And unless someone or something forces us, we probably won’t either.
Disclaimer: I’d like to point out I’ve always been and still am a software developer myself. For the sake of the narrative, it might appear that LCR is some kind of nasty, evil behavior that developers exhibit, but of course, it’s a lot more nuanced than that.
So What Really Causes LCR?
Most software engineers are quite capable and comfortable working on something alone. And that’s really the heart of the matter: staying in our comfort zone.
We usually feel pretty comfortable doing something by ourselves, because we have a good grasp of what it entails. We control and trust our own actions. On top of that, we like to have ownership and the personal feeling of achievement that comes with it.
Unfortunately, there are a couple of complicating factors:
What we personally feel is an achievement or responsible behavior, needs to be aligned with the team, as it is usually only the total result that really matters, not just the single story we’ve given our all to. And we’re cognitively biased: we tend to overestimate our own abilities and at the same time underestimate the abilities of our colleagues.
Sometimes there are other factors in play as well, like fearing to lose face in a group setting. But whatever the case, there’s nothing evil about all this, it’s just human behavior. Trying to be safe and comfortable is something we naturally aim for. As we all know, however, that’s not where the magic happens.
The cause for LCR has nothing to do with software engineers. Some people simply have it a bit more than others but I dare not make any claim that this would be the case with software developers in general.
How can We Tackle the Effects of LCR?
The best short-term solution for avoiding the Lonesome Cowboy Reflex is simply changing the environment, by taking away the possibilities for LCR to occur. In the long term, it’s all about creating positive experiences in a new setting, so the comfort zones of the individuals shift towards the team.
Applying an agile methodology is in itself not good enough to solve this. While it offers a framework for dealing with this, the actual execution is what matters, which can be very hard. In the end, it’s about building and coaching a team.
Effectively tackling LCR starts top-down:
As a project manager: don’t spread your forces too thin
When it comes to resource planning, a lot of times the people controlling the budget tend to aim for a sense of security. When there are 3 projects going on, the project managers all want to know that their project is being worked on *today*. So you’ll see a team split three ways by a push from above.
From a delivery point of view this really is a false sense of security. A better alternative would probably be to have a single team handle items from each project consecutively. If might feel counterintuitive, because someone will feel like they’re taking all the risk, or even being left out entirely. But in effect, we’re lowering the overall risk by improving the focus.
Resist the urge to control people as resources, but work more with the teams as a whole to identify deliverables and build up trust that way. On a program level, make sure that all project managers are on the same page regarding the distribution of their projects and that they can work in a way that feels fair in the long run, rather just day to day.
As a team lead: limit the work in progress and remove obstacles
This is the basic tenet of Kanban, and simply the most effective in the short term. I often see that while stories are prioritized correctly, the “finish one before starting another” approach is not respected on a team level.
The fastest way to force collaboration is to offer no other way out. Try the following: offer a team only a single item to work on and tell them to finish it as soon as possible. While this can appear a bit harsh, it will require every team member to stretch their usual thinking and do something “the hard way”… or do nothing at all.
Be wary, however: you will have to be there to remove obstacles. At times it is necessary that someone helps us past the invisible walls we put up in our heads. Be willing to search for ways to make things possible. Don’t try to tell them how to do something, but simply don’t take no for an answer and do not let up your questions.
As an individual: suppress your own reflexes
I’ve suffered from LCR myself often enough, but I ha(v)(t)e to admit that every time I’ve been forced to go beyond it and truly join forces with other developers, it paid off in the end. Most times even with me thinking something along the lines of “actually that wasn’t so bad and it did go faster”.
Being conscious of our own reflexes and willing to admit we might have slightly warped views on some things, can go a long way in taking actions to improve it.
It’s really all about getting developers to work together on a low enough level: learning by doing, and building experience that transforms individuals into a high-performing team.
Even though this is an oversimplification of an in-no-way-scientific phenomenon, this post is all about improving team performance. Much like in sports, building a good team takes a lot of effort and involves orienting individual strong points towards team results, while retaining personal satisfaction. This means using as much of the entire team’s talent pool, all the time! We often tend to forget that last bit.
I hope I have given you enough information to help identify LCR, along with some ideas on how you can take action to prevent it.
| Published on Java Code Geeks with permission by Arne Vandamme, partner at our JCG program. See the original article here: Improving Agile Team Performance Opinions expressed by Java Code Geeks contributors are their own. |
