Helping Overcome Impediments Between Managers and Agile Teams
Join the DZone community and get the full member experience.Join For Free
Here’s a hypothetical scenario based on my experience:
Mike, the Development Manager at a small company, asked Alice, an Agile coach, to come in and help introduce Agile to his organisation, starting with the key development team.
Alice ran some introductory workshops with Mike and the whole team. At the end of these sessions Mike told everyone “I’m really excited about the potential of Agile to help our organisation, starting with this team. I want to do all that I can to support it”
When Alice came back to the organisation a few weeks later she found that the team were beginning to express doubts about how committed Mike was to adopting Agile. Mike had stopped coming to the daily stand-ups and worse, he wasn’t helping them remove the blockers they experienced with tasks that required a specialist user experience designer in another team.
The team told Alice: “Mike’s not doing anything to remove the delays caused by other teams. He says he supports Agile, but when we need him to help us out, he isn’t there for us. Yet again, the problem is with management! There’s no point us doing this Agile stuff if we’re not supported”
Alice agreed with the team Mike’s role is to help the team by overcoming organisational impediments. She decided to encourage Mike to attend the team’s daily stand-up where she hoped he’d recognise that the reasons for blocks which were causing delays on the tasks were things that he should help with. If Mike didn’t see this for himself, Alice would then model this behaviour for Mike by asking “What would it take to remove the blockers on those tasks? Would you benefit from help on those?” If this fails then Alice would be more direct to Mike by asking “What’s your view on talking to the team about the blockers and seeing how you could help?”
What’s your view of Alice’s approach to helping in this situation? Here’s my view – I welcome your thoughts if you see it differently.
- Alice seems to assume that what the team complain about is valid – that Mike is not helping resolve the causes of the external blockages – without clarifying what the team have said or done to raise the issues they see with Mike. Alice seems to assume that the team’s complaint is valid without checking if the team have raised their issue with Mike.
- Alice doesn’t ask the team for the reasoning behind the assumptions they seem to have made, firstly, that Mike is aware that he isn’t helping them, and secondly, he has deliberately chosen not to help them out. Alice doesn’t ask the team why they seem to think that Mike has deliberately chosen not to help them. It would be useful to focus on directly observable data – what the team has seen Mike do or say that lead them to their views?
- The next question is what have the team said or done to make Mike aware of the situation? Have they been explicit and described their point of view? If not, what, if anything prevented them from doing so?
- Alice seems to jump straight to taking action to help the team out, and in doing so, taking responsibility for them, rather than discussing her approach with the team and giving them an opportunity to handle the situation more effectively.
- Alice’s choice to ‘model’ the ‘correct’ behaviour for Mike, without explicitly saying that this is what she is doing, is an easing-in approach with the manager which may be based on assumptions that the Mike couldn’t handle being told directly. It’s likely that Mike will work out that Alice isn’t being direct with him, but rather than guessing what Alice’s view is, Mike is likely to feel puzzled or confused about what Alice is holding back.
Here are a couple of suggestions for how I think this situation could be dealt with more effectively.
Adopt a mindset of curiosityFirst off, it’s worth trying to adopt a mindset of curiosity rather than certainty about the team’s view of the issue and the meaning and intent behind Mike’s behaviour. It’s common for the team in this situation to believe that they see the whole picture, that Mike is either lacking the right perspective or being deliberately difficult and the team’s task is to illustrate the obviousness of their perspective so that Mike will change. A more productive frame of mind is to believe that the team see many important things, but not the whole situation, Mike may see additional things they don’t and the task is to work together to design a productive way forward.
Focus on getting directly observable evidence rather than assumptionsIt would be useful for Alice to ask the team to tell her what they’ve seen Mike say or avoid doing that leads them to believe he is aware of the blockers and has deliberately chosen not to do anything about them. Getting down to the level of directly observable data – what a video camera would capture – would allow Alice to understand more about the problem and potentially highlight how the team’s behaviour may (inadvertently) be contributing to the situation.
Strive to raise the issue with the people involved at the time it happensAn effective situation would be one where the team were able to raise their concerns directly with Mike and ask if he sees it similarly, or perhaps sees something that they are missing. For example, they might say:
“On our task board, there is a task that is blocked because we’re waiting on another team to do some work for us. Our understanding of the Agile process is that your role is to help us overcome these situations. Does that match your view? If so, can we share our view about what’s causing this blockage and how we could work together with you to remove it?”
In my experience working with teams using the suggestions above has created productive outcomes even in complex situations. I welcome your experiences or views in the comments.
Published at DZone with permission of Benjamin Mitchell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
How To Scan and Validate Image Uploads in Java
Using Render Log Streams to Log to Papertrail
Incident Response Guide
Payments Architecture - An Introduction