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.

Some more Anti-Patterns

• I’m the only one who knows that code or understands the domain and design—I’ve been here the longest and I’m the only one left with a clue about this code. Well…that will remain the situation unless you start letting others in to help you. How about mentoring your “replacement” so you can move onto other things?
• Don’t bring me problems…bring me solutions—this age-old management speak was a façade to allow managers to disengage from their teams. It no longer applies. Anyone and I mean anyone, that can help a team advance…should be engaged to help.
• It’s embarrassing, I don’t want to be the “weakest link” on our team—I actually believe that self-aware and team-centered individuals can find a place where there are no “weak links” on a team. A place where the team covers each other’s weaknesses and simply delivers on their combined strengths.
• I’m trying to have a “can do” or positive attitude—I know, many engineers are infernally optimistic, but let’s also bring a healthy dose of realism and experience into play. Look at your history and be self-aware. Asking for help IS a positive response.
• Everyone thinks I’m perfect—I hate to break this news to you, but no, they don’t. If anyone has worked with you for any length of time, they understand your strengths AND your weaknesses. Including your inability to ask for help…so ask.
• I’ve already started, it will take longer to hand it off to someone else—this aligns nicely with 90% done syndrome. It’s counter-intuitive, but teams swarming around work get it done the quickest. So the push here should be to ask for help and engage others as soon as you can.

However, in the end, all of these are simply excuses for not asking for help. In a way, I think they are mostly ‘selfish’ in that you make them “about you”.

At least from an agile team and project perspective, it’s not about the individual. It’s about the team. Asking for help is an acknowledgement that your team is greater than the sum of its parts, and that you have a responsibility to identify challenges and face them as a team. When you’re unwilling to raise them early and often, you’re not seeing the big picture of collaborative team work towards a common goal.

The “Simplicity” of Agile & Coaching

One of the biggest challenges I find in my coaching is having agile teams ask for help. I can’t tell you how often I’ve found that teams get a brief sense of the agile methods and dive in before they truly know what they’re doing.

Part of the problem is the inherent simplicity of the methods themselves. On the surface, everything sounds so easy. All you need is:

• A self-directed team
• A customer
• A project
• A backlog (list)
• A daily stand-up
• A demo

And life is good…right? Now you’re agile and everything will sort itself out. You simply need to keep ‘sprinting’ and good things will result.

What these teams fail to grasp is that there is a big, no huge, difference in “Doing Agile” vs. “Being Agile”. They’re often focusing on the individual ceremonies or tactics and not truly grasping what it takes to evolve into a well-formed, mature agile team that aligns with the core principles of agility.

Incredibly often, these “doing agile” teams don’t even realize that they’re off track or need help. That is until it’s quite late—when they’ve got a great deal of dysfunction in place. Or when they realize that they’ve failed to deliver on the results that “being agile” teams can produce. Then they reach out for a helping hand, but usually only after a whole lot of waste. As an Agile Project Manager, don’t let your teams fall into this trap. Remind them that agility done well is a complex and continuous journey and that asking for help or getting a coach or guide is an incredibly mature and healthy step.

How to ask for help?

I thought I’d just share a few words of advice in how to think about asking for help. In many ways, it’s a mindset that you have to reframe from your existing perspectives to a new view—you and your team.

Just do it! Don’t think too much about it

Keep your release, sprint and team goals in mind, it’s not about you

It allows the team to solve their problems…not individuals

If you “feel” like you need help…you do

It’s a sign of strength, not weakness

Also, offer to help…whenever possible…and don’t always take “No” for an answer

Solve your problems together

Ask before it’s “too late”; time is the enemy

Craftsmen learn from each other; looking for alternative approaches

Pairing truly helps teams in asking for help; pair often

One wonderful place to explore your personal and your teams’ growth when it comes to asking for help and working together is the retrospective. It should be a ‘safe’ environment for any good team to reflect on their challenges and how they could have improved.

One important area to continuously explore in your retrospectives is the teams’ behaviors around collaborative trust and asking for and providing help. Try talking about how “help friendly” your team is in your retrospectives.

Both Directions

And help is a multi-directional element. Meaning you’ll often find yourself asking for help and providing help…often at the same time. I think the degree to which you offer to help and collaborate will improve your own abilities to ask for and receive help from team members. An easy way to “get better” is helping your own team members—asking probing questions surrounding team challenges and being real in exchanges around getting things done.

This is particularly important at a leadership level in setting an example where asking for help is construed as a positive and normal activity within the team. Where saying “I don’t know”, and “Can you help me with this?” and “What do you think I should do?” are all perceived as mature, healthy, and constructive events within your organization.

I remember reading a leadership book that talked about senior managers asking to be mentored by members of staff. The idea was that they would ask for help from folks who’d been there the longest. That they would show humility and teach-ability by asking for, listening to, and digesting the wisdom these folks could share. And in doing so they created a more collaborative and humble environment where showing vulnerability and asking for assistance was not only OK, but it was the norm.

Wrapping up

Wrapping this article up, I think Agile Project Managers foster an environment where asking for help is considered a strength and always well received. Where team members embrace and welcome the opportunity to help each other out. Where they look at providing two-way help as one of the strengths of their team and their organization

The best way to start this is to lead by example. To show vulnerability yourself and ask for help when it’s appropriate. To occasionally say—“I don’t know” when you’re dealing with daily challenges.  To ask questions of the team when folks appear to be struggling…teasing out who needs help as soon as possible.

So go ask your team to help you, help them, in asking for help…

Here are few follow-up references that I thought I’d share with you. You’ll notice that agile teams aren’t the only ones who struggle asking for help.

Stay agile my friends,

Bob.