A Sad Story

A seasoned Director of Software Development was championing agile adoption at their company. It was a moderately scaled initiative, including perhaps 100 developers, testers, project managers, BAs and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were “good to go” as they started sprinting.

Six months later things were a shambles. Managers were micro-managing the sprints and adjusting team estimates and plans. The teams were distrustful, opaque and misleading their management. There was virtually no honest and open collaboration—nor trust. They’d (re)established a very dysfunctional dance.

Funny thing is…

Their agile coach had asked many times if they needed help and the answer was always: ”No – things are going fine”. Only when they had failed 10 sprints in a row and team members were mutinying, did the Director reach out for help to their coach.

Their coach came back and in relatively short order brought the team back to ‘basics’ and helped them restore balance, trust, collaboration, and commitment to agile delivery. Afterwards, everyone was asking the questions: “Why did it take so long—why didn’t we ask for help sooner?”

Another Sad Story

A set of teams in a mature internet startup had been leveraging Scrum for 4-5 years. They were incredibly mature and were delivering well on the promise that agile has in terms of value delivery, quality, and team morale. Things were going quite well…or so it seemed.

But under the covers, the teams were losing their ‘edge’.  Defects were on the rise. The teams weren’t having impactful retrospectives and really tackling self / continuous improvement. Morale was sort of slipping, and the teams were losing their accountability towards providing great results and real value.

In a word, complacency was seeping into the teams. Funny thing is…

The organization’s agile coach would have a weekly meeting with the Scrum Masters across all of the teams. She would always ask if they needed any help. By attending a planning or grooming session? By co-facilitating a retrospective? By partnering with any of the Scrum Masters in coaching their teams?

But that honest offer of help was never met with a pull-request…in over a year.  Not one of the experienced Scrum Masters directly asked for help. Why not? Instead, they mostly struggled to inspire their teams towards improvement and became comfortable with and defensive of the complacency trending.

And a Final Sad Story

I was coaching several Scrum teams as part of a new adoption. I would count this as a true enterprise-level adoption—in that there were many teams starting all at once across several projects. In order to provide some coaching guidance as they began, I was rotating amongst the various team stand-ups as a ‘chicken’.

There was one team where I noticed one of the software engineers was struggling with their sprint work. In sprint planning, Sue had estimated the work at several days to complete (really the entire team had agreed). But as the sprint unfolded, Sue seemed to be struggling with the complexity of the work. On day 2 of the sprint, she identified that in the stand-up, but was still hopeful. On day 3, she was still working hard, but again, hopeful. On day 4, again…. This continued until the seventh day of the sprint when it was obvious that Sue was struggling and the entire team tried to come to her aid. Regardless of everyone’s efforts, the task was attacked too late and the team failed to deliver on their sprint commitment.

Funny thing is…

This was the team’s number one priority user story for the sprint. They’d all committed to getting it done as part of the sprint’s body of work. Yet, no one seemed interested in the fact that it was running late and jeopardizing the other work they’d committed to and the overall sprint goal. That is, not until the “last minute”.

Beyond that, not a single person on the team asked if they could help her early on OR challenged why she was struggling so as to encourage her to ask for help.  It just dragged out until it was literally…too late.

Help me…where is this going?

In all three of my stories there was a fundamental reluctance for folks to ask for help. Not only that, when they did ask for help, it was often very late in the game and the challenge, issue or problem was greatly exacerbated and much more difficult to tame.

The intent of this article is to explore the dynamics of this common software team anti-pattern. While it’s not directly related to agile, I think it surfaces more frequently in agile teams given the self-directed, collaborative and transparent principles those teams aspire to.

What I’ve noticed in the professional landscape is that folks are truly reluctant to ask for assistance. Is it ego? Is it embarrassment? Is it trust? Is it perception? I think it’s all of these and more.

Why I’m surfacing it now is that I’ve been observing it for years as part of my Agile & Scrum coaching. I see it at all levels of organizations—which my examples try to illustrate. It happens at the senior leadership level, the management level, and at the team level. It’s often independent of a person’s experience. Indeed, there seems to be a relationship between the more experience you have and your reluctance to admit that you don’t know something, or need help in formulating a next step.

Some Anti-Patterns

Below is a list of some of the thought patterns I’ve seen exhibited within teams by folks who don’t want to ask for help. I know there are probably many more, but I do think the list will help to (1) clarify the challenge or problem at hand, and (2) focus us towards improvement in our abilities in asking for help.

• 90% done syndrome—when you get 90% of a project done in the first 10% of time, but the next 10% takes 90% of the remaining time. It implies that we underestimate and should assume that “finishing” a task usually takes longer than we imagine. Delivering software in fully releasable chunks helps manage this.
• I’ve got the best skills for this specific task—a big part of this is ego and the belief that you are the strongest link. Surely this isn’t reality and it certainly doesn’t help to develop the team’s overall skills either. Perhaps you could pair with someone?
• If I want it done right, I’ll do it myself; I don’t trust others to do this work—I really want to work alongside of you as part of your team…not! And do you “always” do it right and get it done, regardless of the complexity? Get real.
• Everyone else is busy too – seems to be an empathetic and honorable approach…as long as you’re making progress. However, the real question is—is everyone working on the highest priority items to meet the sprint’s goals? If not or if something is delayed, then realign.
• I get paid to solve problems—no, you get paid to be a solid team member and to deliver value for your customers. No individual has all of the answers; instead there is great power in collaboration and the wisdom of the crowds.
• I don’t want to disappoint my team—it’s not about you! Believe it or not, your team understands your strengths and weaknesses. They’ll admire your effort and your honesty when you ask for help when you’re struggling.

Wrapping up

Help me here a second. This is getting much too long for one “sitting”. I’ll continue this post in another round where we’ll explore some additional anti-patterns and plot twists.

Until then, stay agile my friends,

Bob.