An important factor of success in agile environment is that team works well together. It is also important for a software engineer to be able to focus for longer periods of time with limited interruptions.

Many companies have solved the challenge of focus and dedication for the team by having a designated role, such as Scrum Master or Producer, who is responsible for managing stakeholder requests, prioritizing them and communicating to the development team.

But sometimes requests can't be evaluated by a responsible person in the first place. There are topics where somebody from the development team needs to have a look as well to help understand the technical side more deeply.

On top of that, sometimes anomalies appear on monitoring dashboards. Network slowdowns, operational issues and many other things might happen during working time and immediate action could be required to fix the issue.

Who should be responsible in this case? How can we ensure that team’s stakeholder relationships stay healthy and help us move forward?

Recently my team, which is responsible for developing an innovative machine learning product for the fashion world, faced a very similar issue.

Engineers were spending a reasonable percentage of their time working on ad-hoc requests from our stakeholders. There was no proven way to track or organize such requests well, so we could not guarantee the level of support we strive for.

At that point we understood that we needed either a clear owner of such topics or a pre-defined collaborative responsibility. It simply did not work out-of-the-box and the team needed to institutionalise the meaning of ownership. And we were up for the challenge.

So the team decided to introduce an internal role in our technical team - a facilitator, or, as we call it - Batman - the role that is perceived more as an honor than a burden, and everyone is comfortable with doing it ad-hoc.

Key principles of the role are:

• Every member of the team shares responsibility for all stakeholder requests and service health, by performing facilitator duties on a shift basis
• Facilitator duties are only valid during working hours

Key benefits of the role:

• Stakeholders are always provided with support within a guaranteed lead time (normally up to 2 hours)
• Knowledge about services and requests is spread more evenly in the team by performing the duties and learning from other team members
• Quantity of ad-hoc requests / issues is always visible on the team’s dashboard

When to set it up?

The role is reasonable when:

• The team is working in a big organization with many external and internal stakeholders
• There are regular incoming ad-hoc requests and/or anomalies on monitoring dashboards
• A reasonable part of the team (40-50%) is busy working on ad-hoc requests during the sprint
• Iteration goals are not achieved regularly because of influx of unplanned work

How to set it up? Make sure to have an open conversation in the team. Acknowledge things that you would like to take care of. Spend some time on agreeing within the team of what it means and how it should work. The final definition and duties of the role can be different, everything depends on the team and skill set within the team.

Here are a few important guidelines we want to share that helped us to set up the role:

• Define a clear set of expectations from the role, make sure duties are well described and understood by the team and stakeholders
• Set up a schedule for taking on the role and make sure it is flexible enough.
• Weekly shifts have proven to be optimal for our team.
• Rule of thumb: no person should do two shifts in a row.
• Clearly define what is not within the scope of the role.
• Set up F.A.Q. section and maintain it, it will serve both team and stakeholders well.
• Consider talking about the role actively in team retrospectives, or even having a dedicated retrospective about the role every 1-2 months. Openly talking about successes and challenges helps to adjust the process.
• Count in the amount of time needed to perform the duties during planning.
• Set up a short handover meeting for remaining tasks from the previous shift.
• Document the findings, so the need for the role fades away with time (invest in proper runbooks and knowledge sharings)

What is the feedback from the team regarding the role?

• Structured approach to ad-hoc requests is a big plus.
• Noticeable improvement in knowledge sharing among team members.
• Everyone should assume equal responsibility when doing the facilitator job.
• The role only works well if everybody in the team embraces it and is diligent when performing facilitator duties.
• When the team has different backgrounds (for example, backend engineering and research engineering), the time is needed to adjust to each other’s technical stack and way of thinking.
• Handover of existing requests needs to be thought through better.
• Sometimes there are not enough small tickets to pick up by the team member on the facilitator shift.

What is next?

We truly believe that talking about the role and how it develops helps us to adjust the process as we move forward.

We will continue developing the role inside our team to help us become even better.