How to create a safe environment in the Agile Retro


HOW TO CREATE A SAFE ENVIRONMENT IN THE AGILE RETRO
Hi guys, this week I want to help you with a topic that pops up quite often, I want to explain how you can create a safe environment in the agile retro. A lot of people come to me and ask me how can we help team members to say whatever they feel? Sometimes people do not feel comfortable to share everything.
One possibility to improve the situation can be by using a tool I learned about some time ago in the ORSC (Organisational Relationship System Coaching) training: Designing the Partnership Alliance (DTA).
The ORSC explains that the designed alliance requires different complexity. They recommend we should coach other people to design alliance between each other. The first thing what is recommended is to get clear agreements and expectations between team members.
Team members are encouraged to openly discuss their desires and wants and what do they seek to achieve. It´s important they state and express the values. They should also pay attention to not express how they want OTHER to be, but how THEY can commit to be in that particular work relationship.
This aspect is important because it will create a basis, a platform from which the rest of the work will happen. To design partnership alliance, the coach´s job is to help team members to find alignment and purpose. This way they are already designing their culture and are shown to be accountable for maintaining it.
DTA is a powerful tool. It provides the format to help teams get clear about agreements. Research by Fredrickson & Losada (2005) shows that increasing the positivity on a team also increases their productivity. According to Gutman (2008) teams that create decision-making protocols do better than teams without those agreements.
The DTA should emphasise following issues:
• Creating culture – this is the environment that team members want to create. The benefit of defining the environment is that if certain factors change or affect your project or anything else, the atmosphere will still bond.
• Sharing responsibility – each team member is co-responsible in creating culture or behaviour that is appropriate and wanted in a team. Accountability helps create empowered teams.
Useful questions we should ask:
• “What is the culture, space or atmosphere you want to create in the team? How would you know you had that?”
• “How do you want it to feel?” (Empowering, supportive, etc.)
For teams or work partnerships:
“What kind of culture or climate do you want to create together? What are the values you want it to live by as a team? How would you know you had that?”
• “How do you want to behave together when things get difficult, or when there is conflict? (Who do you want to be together?) What are the team´s conflict protocols?”
• “What would help the team to flourish?”
• “What can your team or system count on from you?”
• “What will you each commit to for one another? How would you know you had that?”
Together with creating the atmosphere of your desired culture, it´s crucial for teams to have certain behavioural agreements. You can decide on whichever agreements you wish for, for instance, agreements about using PCs in meetings, about decision making, responsibility, etc. These kind of agreements are the behavioural definition of the culture that the team would like to create.
The DTA is not only a tool for the initial session; it can also be used by teams and partnerships for any upcoming event. The DTA can be also used in families or relationships.
In such occasions, they are also designing behavioural agreements, but they might not be aware of it. For example, agreements about household chores, who takes the kids to school, about cooking, etc.
The DTA should be updated time to time, as any changes happen. Each team member should be encouraged to follow these agreements. It is also important that DTA is visible and easily accessible to everyone in a team.
I believe this can be a fantastic tool for teams that want to design a culture where everyone´s voice is heard and respected. Everyone has an opinion that should be honoured.
ORGANISATIONAL MASTERY SCORECARD
We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.
Take The TestIf you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.
Since many software development teams, particularly those have adopted – or rather ordered to adopt – Agile, are using external staff to develop software, team cohesiveness and common values are moot.
These developers are focused on one thing and one thing only: Their contract end dates, which are typically set no more than a handful of months into the future. If any other consideration is afforded mindspace it is how to ensure they will get their contracts extended.
But they all know, some day, even with the burden of Agile to delay things, the project will be finished, or abandoned, and the moment that happens they developers are all out of a job.
This is how software development really happens. Teams of contractors and out-sourced body-shoppers, being bought temporarily together by an avericious management that plans to terminate all their contracts the moment the software under development is in a state that it can be sold to customers (a state that usually falls well short of “working”).
Under these conditions you are not going to be able to create any kind of team. You have a group of individuals, each of whom are facing unemployment everytime they handover a completed “story”. It doesn’t matter what techniques you use here to “motivate” them. Their livliehoods are on the line and that is all they are going to be thinking about.
“Oh no”, they say, “if you write the best software, you will be top of the contract extension list. So long as you can deliver the finished goods within two days, that is. Otherwise we’ll extend the contract for the other guy who can always up come up with a quick hack that appears to work sufficient to get us through to the next sprint”.
Still, good luck with what you’re doing. Just remember, those “negative energy” guys who give you weird looks when you’re trying to motivate them, are doing so because they understand the situation they are in a whole let better than you. Asking them to sign “partnership agreements” which each other might sound good on paper, but you’ll find most of us aren’t really all that interested in “partnering” with someone who will have a knife in our back every two months when the contract extenstions become due.
Thanks but I do not see how your comment is related with the blog post 🙂
Hello, Very good insight. I have used many ideas from blogs. I do struggle with the team of researchers who does not see any value of agile however go thru ceremonies as part of company policy. Could you suggest few examples of retro which are done for research team.