Six months later things were in shambles. Managers were micromanaging the sprints and adjusting team estimates and plans. The teams were distrustful, opaque and misleading their management.
- Another Sad Story
- And a Final Sad Story
- Help Me… Where is This Going?
- Some Anti-Patterns
- The ‘Simplicity’ of Agile Coaching
- How to Ask for Help?
- Both Directions
- Wrapping Up and a Survey
There was virtually no honest and open collaboration or trust. They’d (re)established a 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 ten sprints in a row and team members were mutinying, did the director reach out for help to the coach.
The coach came back and in short order brought the team back to basics and helped them restore balance, trust, collaboration, and commitment to agile delivery. Afterward, everyone asked these questions: “Why did it take so long,” and “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 agile holds 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 slipping, and the teams were losing their accountability toward providing great results and real value.
In a word, complacency had seeped 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 help. By her attending a planning or grooming session? By her co-facilitating a retrospective? By her partnering with any of the Scrum Masters in coaching their teams?
But her 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 toward 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 there were many teams starting at once across several projects. In order to provide some coaching guidance as they began, I rotated amongst the various team stand-ups as a chicken.
There was one team where I noticed one of the software engineers was struggling with her sprint work. In sprint planning, Sue had estimated the work at several days to complete (the entire team had agreed). But as the sprint unfolded, Sue seemed struggle with the complexity of the work. On day two of the sprint, she identified the issue in the stand-up, but was still hopeful. On day three, she was still working hard, but again, hopeful. On day four, 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 stories there was a fundamental reluctance for folks to ask for help. Not only that, when they did ask for help, it was often 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 because 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
- 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 lies in, 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.
- 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 eventual 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 the 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 the 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 teams 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 teamwork toward a common goal.
Want tips on how to improve your agile teams' performance?
Watch our free webinar, Essential Patterns of Mature Agile Teams. Apply password “ZenWeb” to watch.
The 'Simplicity' of Agile Coaching
One of the biggest challenges I find in my coaching is Agile teams not asking for help. Often teams get a brief sense of 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 there is a 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.
Too often, these doing Agile teams don’t even realize 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 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 agile teams fall into this trap. Remind them that agility done well is a complex and continuous journey and asking for help or getting a coach or guide is an incredibly mature and healthy step.
How to Ask for Help?
I want to share a few words of advice in how to think about asking for help. In many ways, it’s a mindset you must reframe from your existing perspectives to a new view, you and your team.
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.
Another 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
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 by 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 they would ask for help from folks who’d been there the longest. They would show humility and teach-ability by asking for, listening to, and digesting the wisdom these folks could share. 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 and a Survey
A while ago I wrote a blog post about teams handling failure and failing. As part of the post, I created a short survey to poll readers and get a sense for the state of failure acceptance in the real world. The premise was my personal lens might be a bit skewed and I wanted to get other perspectives. In this case it turned out the environment for failure acceptance was even worse than I had imagined. The results were interesting, but sad as well.
I’m inspired to try the same approach with this topic. I’ve created a relatively short survey surrounding organizational health (team, management, senior leadership) when it comes to asking for help. Here’s a link – http://goo.gl/CFVY4
And I need your help in filling it out.
To wrap up, I think Agile project managers should 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. 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 and ask for help when appropriate. To occasionally say, “I don’t know,” when you’re dealing with daily challenges and to ask questions of the team when folks appear to be struggling, teases out who needs help as soon as possible.
So go ask your team to help you, help them, in asking for help…
Here is a follow-up references I want to share with you. You’ll notice that Agile teams aren’t the only ones who struggle asking for help.
Stay Agile my friends!
Bob.
Up Next:
- Caught in the Middle: How to Balance Agile Team Needs with Wayward Management Requests >> Read
- The Agile Project Manager – Fail NOW as a Strategy >> Read
How do you view failure in your organization?
Explore how failure helps your teams reach greater success: Agile Project Manager – Fail Now as a Strategy.
