Solution Architecture Retrospective Feedback

The worldwide Solution Architecture team, as a learning organization believes that we can be more successful by receiving feedback. Feedback is a two-way street. It is important that SA management takes the time to provide feedback on a regular basis to their individual team members, but simoultanously GitLab team members should share their feedback with management and peers. During this two-way feedback exchange, it provides SAs insights into their activities working with customers and internal processes as well as the SA management insights into their leadership skills.

Solution Architecture Retrospective Feedback

GitLab as an organization being fully remote, encourages Solutions Architecture groups and other teams to run agile retrospective feedback sessions. As an organization operating in various worldwide regions, we are distributed and coming together in-person in a meeting room may not always be possible. In the spirit of one of our company values Iteration it gives us an opportunity to hold agile retrospective meetings that follow similar software development principles in the context of our engagements to educate and enable our customers. During the retrospective, the team reflects on what happend in the iteration and focussed on actions to be taken to improve going forward.

On a high-level goal, we are trying to understand what happened in a given time period (on a quarterly basis for instance), with a goal to improve “things” in the upcoming time period which is stricly based on those learning and discussions.

We suggest for teams to pause and reflect on what transpired and encourage collaboration to distinguish between what worked from what didn’t work during a particular time period. It also allows for Solution Architecture teams to re-align given field observations coming from our customers.

The following diagram shows the Solution Architecture Retrospective Overview.

Solution Architecture Retrospective feedback critically impacts customers and other cross-functional teams, including Product, Sales and Marketing. Based on the retrospection insights, Solution Architects can improve product alignment and prioritisation. Apart from the Solution Architecture team, many other cross-functional teams will benefit from Solution Architecture Retrospection Feedback and use it to improve internal alignment and enhance the customer-centric approach.

What is an agile retrospective feedback session?

Agile feedback retrospective sessions can end up in pointing out the flaws and challenges which teams encounter. However, it is important that team members also equally consider to bring up positive experiences and iterate on improvements which can increase productivity and efficiency in their roles.

Retrospective feedback sessions should ideally consider 3 areas:

1. “I’m glad that…” » Green

2. “I’m wondering about…” » Yellow

3. “It wasn’t so great that…” » Red

The Solution Architecture team utilizes Postfacto as the main technology for agile retrospective feedback sessions. This is a digital whiteboard tool. The GitLab SA team has configured and implemented it internally. We run private retros which generally are password protected for teams. This Postfacto internal session is hosted within our internal environment and are not publically accessable. Since it is an internally hosted solution, it is available to all internal GitLab teams and not only restricted to the SA team.

Access instructions for our internal Postfacto instance

How can I host a retrospective feedback session with Postfacto

The summary steps are as follows:

1. Use the Postfacto account to log in to the Postfacto panel.
2. Create a retro for the retrospective feedback session you plan to host.
3. Share the retro URL and the password with the participants before the retrospective feedback session.

For details, please refer to this document (Internal members only).

A walk-through of setting up a new restrospective can be found in the video below.

What are the roles during an agile retrospective feedback session?

Agile retros are commonly used as a practise withing engineering teams. However, the GitLab SA groups has implemented a way to reflect on how we work in order to become better in what we do. One of our approaches is the benefit of hosting retrospectives. We hold retrospective sessions towards the end of our fiscal quarter to seek feedback (but that is not restricted to that period only). In the context of our group, the Solutions Architecture leader (i.e. SA Manager, SA Director, SA VP etc.) takes the lead as the host of the restrospective workshop by creating a safe space to gather peoples’ opinions, fascilitating discussion and identifying what the team members need.

The entire group in the retrospective workshop becomes a participant with the opportunity to collaborate, share insights and have a voice.

The host of the restrospective feedback session is encouraged to share the screen over zoom or when in-person, project the retro board for everyone.

Recommended guidance for all retro participants:

• Become an effective listener during the session

• be open-minded and consider every participants experience and opinion

• A retro feedback is not meant to be taken personally

• Focus on actions to drive improvements within the team

• A retro session does not need to run for more than 60 mins

How do I participate in an agile retrospective feedback session?

We encourage that SA Leaders execute retros on a regular basis proactively. However, it is also encourages that individual team members help monitor the frequency of retros and also proactively engage by requesting sessions. As the team leader, we are responsible to be inclusive to invite the entire team making everyone a participant. Optionally the team leader can include relevant team members from immediate teams/groups to participate.

The following activities are required to hold a retrospective session:

1. A Postfacto session with an URL and password (assigned during retro configuration)

2. A calendar invite with the access to the retro session

3. Optionally: a meeting notes document to record actions from the retro

It is recommended to create a new retro board ahead of time by setting a name and chosing an URL. This will allow participants to start providing feedback in the Postfacto tool ahead of time by adding retro items to each column for discussion. During that time team members are also encouraged to start voting if they feel strongly about already raised insights/suggestions (by clicking on the heart icon).

How do I start and end a retro session?

Given the nature of retros are considering opportunities to celebrate improvements (“Happy”), or trying to obtain more clarity around specific topics (“Wondering”) or suggest opportunities for improvement (“Sad?”), those are the discussion columns within the retro board. It is suggested to start by picking a first retro item randomly but considering the number of votes of hearts. The retro host is keeping an eye on the retro time-frame which has a 5-minute timer in the retro item (can be configured).

The guide for the retro item discussion also requires to add actions to improve teamwork. The team needs to nominate a team member to capture actions in either the Postfacto retro tool (at the bottom of the UI) or in a seperate team meeting notes document.

The community around the open-source Postfacto technology and its partners/collaborators have also built this blog “How to Run a Really Good Retrospective” for further guidance.

Important note: The retro time-frame should not be more than 5-minutes per item, as a result of that and for an effective discussion, the participants do not need to go into extensive descriptions “why” that particular item is critical nor into “trying to identify” a solution. The idea for the discussion is to quickly reflect and suggest a best next step or an action. The action then will become a means to identify a solution.

As the agile retro host, close the retro by reflecting on the session and thanking the team for their candid and honest feedback. Focus on great accomplishments of the team and the great interaction during the session.

Follow-up and challenge takeaways

There are a few ways to take the action items from the retro and integrate them into the ways of working depending on the scope of the actions.

For small items changes can be made immediately, updating documents and handbook pages.

When looking at larger changes to processes the best course of action is to integrate these action items into cross-functional OKRs. Especially in these cases with cross-functional process changes it is important to socialise these changes in the appropriate slack channels as well.