If you listen to conversations today, there only seems to be a time before and after Corona. This is the same for me. As a Scrum Master (SM) in the Scaled Agile Framework (SAFe) Environment in a customer's IT program, Corona did not affect me as much as employees in other industries. But it is a challenge to take over an agile team remotely. It's a new situation for all those involved in this environment, since working remotely was not as common before. For the Product Owner (PO), the team members and the Release Train Engineer (RTE).
In my case, I took over an agile team that had not previously been managed in an agile way and could not be onboarded in PI Planning like the other teams. This led to general frustration and a negative mood. In addition, there were no (agile) structures and the work packages had not been bundled according to SAFe. Uncertainties about what features are, how epics are used and how big the stories have to be cut didn't help the team to feel better. The team was not only preoccupied with the uncertainty regarding the content of the work, but also with how to deal with each other. Most of the team members had never seen each other before - only heard each other's voices via Skype.
Above all we all know the problems that remote workshops or Scrum ceremonies can cause. In calls people who are more dominant by nature were more likely to be heard and perceived than people who are more reserved. The dissatisfaction felt in the team was apparent to me already in the first call.
I was faced with the challenge of getting a frustrated team back on track. Of course, I not only want the team to get structure, but also that the team enjoys working together. In my opinion, each team member can only deliver the best possible work if they feel accepted, valued and comfortable.
For the first two sprints I tried to do the normal Scrum ceremonies and work through the sprints. It quickly became clear that the team had not been enabled to continue working according to SAFe or Scrum due to their history. Because of this we used an entire sprint only for the planning and processing of the non-existent structures. At the same time, we also used the newly gained time for team building.
Before I could even think about how to approach this situation, I had to think about which tool to use for the remote workshops. As each tool (Skype, Webex, Teams, Zoom) has its advantages and disadvantages.
Since there are many external consultants in our team, we decided to use Microsoft teams. With teams we have the possibility to use channels under the main group. So we created different channels for working groups (divided by topics). The onboarding of the team to the new tool was a new challenge, but the team quickly recognized the advantage and has since learned to appreciate it.
Apart from the lack of structure and team cohesion, the project assignment was not clear. Therefore the product manager was also invited to the workshops, so that not only the PO but also the team had the opportunity to clarify open questions directly with the product manager every day.
I brought along an excerpt from the workshop agenda:
Check In - Check Out
The decisive factor for me was that the team had a "check in" in the morning and a "check out" in the evening by means of a short retro.
The daily check in's with the camera created closeness to each other, because you could see each other every day and could not hide behind the screen. Already after the 3rd day you could feel how the team approached each other. Of course, not only the check in's helped that the developers acted more and more as a team. Also the intensive cooperation during the workshop helped to bring the team closer together. The presence of the product manager brought a certain commitment and also a certain positive pressure.
The clearly defined goals for each day also helped the team to focus.
Presentation work status:
Every day the team members had to present their work status to the PO, Scrum Master and the Product Manager. This created a short feedback cycle and changes could be incorporated immediately and questions answered at the same time. In addition, due to time pressure the team was "forced" to have the courage towards a gap and take a certain risk (agile principles). Since the progress was immediately visible, the team gained new motivation and confidence that they would be integrated into a regulated, agile working mode at the end of the workshop. The joint achievement of goals is of great importance for team building, which became very clear in this case.
Another realization was that all team members and PO had to be present in Microsoft Teams online or in the main group the whole day. This gave the opportunity, just like in the office, to simply talk to someone and clarify questions directly without having to make long phone calls or wait for a call back. Of course, this meant that all team members including PO had to block the entire workshop days completely.
If somebody had to attend another appointment during the day, a short message was sent in the chat with the information when they would be back. In this way a physical workspace was simulated and this worked perfectly.
If an agile team, due to whatever circumstances, gets into a state where the path seems hopeless, a temporary 1:1 support of the Scrum Master as well as the PO can strengthen the team. If the team works remotely and does not (yet) know each other personally, workshops are a great opportunity to weld the team together into one unit, to get a common understanding of the content and to prepare for an onboarding into the running project. Sometimes you have to take a step back to move forward again.
Today, about 3 months and 2 PI's later, still in a special situation through Covid19, I can say with joy and pride that my team is doing a very good job and the cohesion is noticeable every day. We also have a lot of fun working together and we know each other so well that we can laugh together. From a frustrated, de-motivated team to a strong, well-positioned team that supports each other and works together towards a goal.