Can big room planning be done digitally and remotely?

July 3rd, 2020

When the world is changing, there is no other way to thrive than to adapt and evolve. With that in mind, what do you do when you are used to having big room planning meetings to support your agile software development, but you can’t meet face-to-face because of the ongoing Corona virus pandemic?

 You go digital and you go remote!

At the end of May, WirelessCar held  our very first digital Program Increment (PI) Planning and the lessons learned will help us be more robust in the future and evolve our planning even further.


Why PI planning?

To manage software development at scale with many customers, complex solutions and numerous internal dependencies between  development and operations teams, we have been following a WirelessCar-tailored Scaled Agile Framework (SAFe ) implementation. It has given us an edge and a mindset to tackle and adapt to any unexpected situation.

Every 12 weeks, for the past 3 years, all DevOps teams, the WirelessCar management team and customer representatives have met for two fun, focused and fruitful days of planning together. Aligning our context, exploring customer needs, moving forward with speed, planning together these planning sessions enable us to prioritise value-adding activities, maximise flexibility and learn from each other.

The Corona crisis has meant that we have had to find new ways to do the same things but to do them differently. As a digital, agile organization at the forefront of mobility software development in the automotive industry, we are used to fast changes and uncharted territory.

So, we took up the challenge, harnessed our agile spirit and adapted our way of working.

Firstly, in record time, we worked with our planned development remotely when the Swedish Public Health Agency recommended to work from home, and then we executed a full scale digital and remote PI planning.

We followed up with WirelessCar’s Way of Working expert Martin Guirguis, and Scrum Masters/Delivery leads, Aleksandra Mårtensson and Maria Bindekrans, and asked what  others should think about if they are considering to adopt an agile approach or if you need to start working digitally.

We’d love to hear your thoughts on this so we can help each other evolve!


Simplicity, security and setting the scene

When the Swedish Public Health Agency recommended that people should work from home, we quickly had to enable that and find ways to do team planning and day to day work remotely.

That, in turn, triggered the need to prepare a fully digital and remote PI planning. We put together a reference group of scrum masters and way of working professionals. This group looked at the benefits we wanted to achieve (structural and functional), potential collaboration tools, security issues, as well as budget needs and limitations.

One thing that was extremely important, especially when choosing the collaboration tools, was to secure where our and our customers’ data should be stored to avoid potential exposure. The group tried different tools, did a small-scale PI planning simulation with people from teams who work in different ways.

After the evaluation, a cost-efficient solution was selected that focused on simplicity, security, and setting the scene; putting established ways of communication and people’s interactions, alignment and transparency first.

The main goal was to enhance the teams’ existing dynamics and planning techniques and only adapt to a changed format. In a regular PI planning the teams would use post-it notes, on a planning board and use the red thread to visualize dependencies. This time the post-it notes were replaced by Jira tickets; the planning board became a Confluence page; and dependencies were listed in a table on that same page.

The planning team also prepared information and training before the actual event to avoid issues with the format during planning days. To improve transparency, a PI planning info page on Confluence was created, containing the agenda, how-to guides, seating list/list of meeting links, working agreements and meeting etiquette. This was very appreciated and was reflected in the final participant feedback where the event got 4.1 on a five-point scale.


Finding out about everything from fika to long-term benefits

So, at the end of May, for 2 days, 8 release trains, 28 teams, hundreds of people were involved in  a remote digital PI planning. These are our 9 key findings:

  1. Format: As a first digital/remote PI, it was appreciated to try and keep the way of working and only change the format, as well as to keep it as simple as possible. That maximized the output. As a next step however, if this turns into a more permanent set up, the actual way of working could be adjusted to better benefit from the digital tools and format.
  2. Online meetings: Doing planning in front of a screen sometimes made it harder to be focused and present. For example, you do not see each other that well and you have your computer and all your other tasks on your to-do-list at your fingertips. Better interactions required different roles in the meetings (i.e. one person leading the discussion and sharing the screen, one viewing who entered the meeting and what happened in the meeting chat, one keeping track of time/the agenda) and it was also important that everyone was actively encouraged to verbally share what was on their mind.
  3. Digitalized planning board benefits: Digitalized planning was in many ways more efficient. For example, since the plan was digitalized directly and did not have to be digitalized afterwards. With smart filters in Confluence, the post-it notes/Jira tickets could automatically be placed on the Confluence planning board.
    Another thing that made it more efficient was that you could visit another team “room” very quickly to compare plans and discuss dependencies, etc. instead of having to run between floors, actual meeting rooms and physical planning boards. Moreover, with all the planning boards easily available to everyone, information about plans and scopes for other teams was more accessible, which was appreciated.
    The Confluence boards are now used to communicate with the customer, the management team and other stakeholders. This increases transparency and decreases the risk for things getting “lost in translation.”
  4. Different time zones: Usually team members located at other sites would come to Gothenburg to be participate face-to-face. Working remotely, the time difference had to be considered. A solution to avoid working outside of office hours too much is to spread the planning over more days and prepare more diligently ahead of the planning sessions. This might be considered an inconvenience, but on the other hand, digitalized and remote PI planning allows team members who usually do not travel or take part in the planning to participate and experience it, which improves team collaboration.
  5. The social event: Many teams also mentioned that they missed the social parts of the event, e.g. the spontaneous talks by the coffee machine, the fikas, and team bonding. How can that be addressed? The best and most efficient way to talk about software development is still face-to-face. Maybe future events need to be face-to-face events instead of remote even if we keep the digital planning? This might be even more important if working from home will be more common “post corona.”
  6. Breaks: During a regular PI planning there are scheduled pauses, where you get energized. Online meeting after online meeting, with a lot to do, makes it easy not to prioritize breaks, even though it is even more important if you sit in front of a screen instead of standing next to a planning board. Another benefit of the fika breaks is the overhearing and spontaneous dialogues that also secure that unnoticed issues are being solved as well. This need to be addressed better.
  7. Time allocation: Does a digital and remote planning need to take the same amount of time as a face-to-face planning? That is what we allocated this time, but it is something to review. Some aspects show it should be shorter (the plan is digitalized right away; it is faster to visit other teams; or break out for smaller parallel discussions), while other aspects indicate that more time should be allocated for remote planning (e.g. the time zone question, the tech issues, the slower conversations that online meetings bring vs face-2-face). The important finding is to not assume the same time is needed but rather look at your own context and adapt to avoid stress. Maybe more days, but not necessarily full days is a way forward?
  8. Customer interactions: With a digitalized planning it is easier for customers to get involved despite the physical distance, when only hours instead of days need to be allocated. This is something we want to explore more, since customers input on the business value and prioritizations is very helpful. It can also help our customers to adopt more agile ways of working and align with WirelessCar processes.
  9. Tech: Always test, test and test again to see that the tech is working. Having trouble with VPN, bandwidth, etc. affects the planning, so backup communication channels should always be considered.

In conclusion… great preparations, committed and curious teams, as well as the fact that we kept it simple and secure. We received great feedback from a widespread retrospective and, by applying the learnings above, there is also great potential to do things even better.

Many of the teams missed the social aspect of our planning days. So, even if we keep the digitalized format, we probably want to get back to doing future plannings face-to- face. Meeting in real life might even be more important moving forward if the remote working situation is here to stay.

Finally, being ready and able to do both types of planning, has made us much less vulnerable to changes in the world around us. We adapt, we learn, and we get the job done.

If you want to know more about our findings, ways of working or share your own experiences, please contact Martin Guirguis.


Elin Engkvist
Head of Internal Communications & Sustainability