Impediment Removal Team (part II)

This is continued from Thoughts of an Agile Coach (Part I). 

Here's what happened two days ago:

First, let me start with some background. At the most recent Impediment Removal Team (IRT) meeting, one of our strongest scrum masters raised an impediment that the QA environment her team uses is unstable, to such an extent that it crushed in a middle of her team's demo. She circulated a list of 7 distinct instances related to management/stability of  this environment that happened within 2 weeks prior to IRT meeting. In the instance of ruined demo, for example, the team found out that URL was changed to this environment by some other team without notifying them. It was an obvious communication issue, so at the IRT meeting, we decided on two action items:

1. Streamline communication related to environments management. Update the environments ownership list on wiki and communicate to all teams. Keep updating the list at least 24 hours to every change.

2. Notifications on any work in QA or staging environments have to go as e-mails to the team's distribution list, not just the dev lead who may be on vacation or unavailable.

This was straightforward, we got the list updated, provisioning policy re-circulated, and I thought this closed communications part of this item.

What is my concern though is that I was unaware of what happen after IRT meeting. I thought we came up with action items to improve communication and streamline environment ownership. I made sure these action items were completed and felt good about the work done. 

Here's what I came to know. After the IRT, the scrum master was accused of escalated unnecessarily before talking to the right person. She felt horrible and told me that her IRT experience was totally negative and she will never bring any item to IRT attention again because it ends with her being accused of escalating without reason. 

 I could not believe it - I pride IRT for being aimed at resolving impediments while keeping root cause analysis out of scope (it gets frequently implied in the action items, but this is not the goal) - we are targeting impediment removal and we are good about it. This was my principle.

Anyway, I am facing a dilemma now:

1. Ignore this case, too late anyway (has been a week already), one party undercommunicated, another party did not pay attention. Going forward, I will make sure that at the meeting, I explicitly make a statement of the goal and ask for any cases of finger pointing rather than productive issue resolution be reported to me directly.

2. Do the root cause analysis and find who is in fact responsible. There are a lot of things that sound wrong in the "communicated but ignored by the team" theory. However, I won't understand better until I dig deeper. If I do, it will be about finding who made the mistake and blame for the wrongdoing. This would mean be contrary to what I believe in, but it would help the scrum master who has been accused of miscommunication. Should I?

Impediment Removal Team (part I)

Being an overall successful agile transformation, every day brings new surprises. Here another one. I chair an Impediment Removal Team (IRT), which has a beautiful goal of removing impediments which cannot be removed otherwise. So if a team member tried, then a scrum master tried, then it was raised at Scrum of Scrums and could not be removed, the impediment is raised at IRT which consists of C- and VP-level executives who are in a position to make the decision. Most of the impediments are resolved right at the IRT meeting, but event if not, we always come up with a set of action items which lead to the impediment being removed in a matter of days. When there are no impediments raised, we just cancel this weekly meeting. It is not good for emergencies obviously, but it works really well to resolve repeating coordination, communication, or process-related issues, as well to make major decisions regarding technologies, tools, resources, roles, and many other long-term concerns. We make sure that both parties are invited, the one who raised the issue and the one who they think is responsible or may be able to help. I made a special emphasis on the goal being removing the impediments, so we do not do root cause analysis or ask "whose fault is this", especially because the impediments are mostly about the process, not about individuals performing their duties. Prior to IRT, ideally at least 24 hours before the meeting, the scrum master who raised an impediment sends out a brief description of the issue, and what has been done to resolve.

IRT is not my idea, it was suggested by my trainer, Joe Little, when I took my CSM class in response to my questions about scaling Agile at an enterprise level, but I have been thinking we gave it our own twist and made it work. We got solid support and encouragement from our CTO who is ready to attend, listen actively, make decisions, and empower teams to execute. My manager, Executive Director for Agile Practices, encouraged and actively supported the IRT and has been helping to drive it through. Participants showed up and actively contributed. I thought things were going pretty well until two days ago.

In my next posting, I will tell you what happened two days ago.