One of the best benefits of Scrum [1] is the built-in reflection happening in retrospectives after each sprint, but that’s not enough. Reflection cannot always wait until the end of the sprint, reflection – the manifestation of inspect and adapt should happen whenever needed. There needs to be room for informal discussions at all times, not just at the end of the sprint. If any team member has concerns that we, as a team, are moving in the wrong direction, there needs to be psychological safety to allow anyone in the team to “stop the production line” and to engage the team into reflection. The responsibility for such psychological safety lies on every team member – not just the Scrum Master.
In my over-10-year-journey with Our Great Team, the best moments have been exactly these kinds of reflections – in the middle of the sprint, at the utmost inconvenience. Sometimes, no change to our approach was made, but our confidence was boosted by the process of questioning. But more often, these resulted in changing the approach leading to a better outcome than expected. Don’t get me wrong, I’m not proposing to forget about retrospectives, just to highlight that relying solely on them for inspection and adaptation will not be enough. Let’s take a little look at these reflections that manifest themselves as discussions.
Reflection/Discussions and the Agile Manifesto
If you look at the Agile Manifesto [2] principle 12/12 that retrospectives in Scrum aim to fulfill:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is related to ways of working, but software development – as any collaboration – is more than that. There are open questions and dependencies blocking work, there are inter-personal conflicts, there is collaboration with customers and third parties and there is the human need for connection – not feeling excluded from the team. You cannot have true agility without a vibrant discussion culture. Continuous discussion is needed to meet all Agile Manifesto values:
- Individuals and interactions – it literally says interactions, in plural, implying multiple discussions
- Working software – creating software is teamwork and you need to communicate with your team-mates not just once a day at the daily scrum but all the time
- Customer collaboration – again it literally says collaboration, of which the majority is via communications
- Responding to change – discussion is needed to determine how to respond to change and to review if the chosen approach is working
Finally, agile development is a self-organized activity, and you can’t self-organize your team without discussion and to be precise – continuous discussion. Otherwise, it is not self-organized, but dictated by someone. Self-organization is an on-going process, you don’t do it once and but instead it needs to evolve all the time to best facilitate the team. Self-organization is also fragile, unless you have psychological safety for everyone maintained by everyone to raise concerns and voice ideas, you won’t be able to succeed long-term. You need constant reflection.
Reflection/Discussions and “Established” Paradigms
In established software development teamwork research, there is a concept of Teamwork Quality [3] & [4] which consists of the following sub-concepts:
Communication, Coordination, Balance of member contribution, Mutual support, Effort and Cohesion.
What’s worth highlighting are the quality attributes for communication, which are frequency and formalization. The larger the frequency the better and the less formal the better. So, a “loud” team is better than a “quiet” one… I’m making this childish note, because of a nickname our team gained (before the Covid19-times). Our team was called the loudest team at Siili and our team popped up several times in work-place surveys as causing difficulty for other teams to concentrate because of the vivid and often loud conversations. Although I felt sorry for the poor colleagues suffering from our loud discussions, I felt even more sorry for these colleagues because seeing a well-functioning and happy team engaged (often in non-work-related) discussions probably annoyed the folks stuck in their hushed teams with little room for spreading joy or voicing concerns. We were proud to be the loudest team in the company!
(And there are always ways to isolate loud teams if there is a will and I do understand the need for quiet spaces.)
What comes to Teamwork Quality, I’m sure having an open and informal communication culture helps also in coordination, mutual support and cohesion.
Let’s look at learning as well, learning is a core process advocated by the Agile Manifesto – helping us learn from past experience and becoming better at embracing the constant change in our environment. What is the relationship of discussions and learning? First, I’m thinking about the Socratic Dialogue [5], where dialogue is the way to create knowledge and learn. This method has been promoted by practically everyone in the pedagogics community for the past 100 years. But let’s examine learning specifically in teams in a work-place context. I’m thinking especially about learning that is related to the creation of new knowledge and evolving as an expert – something you would like to see in an excellent agile software development team and as advocated by my fellow Finn Kirsti Lonka [6]. This kind of learning requires a lot of reflection, but not just by the individual, but also among peers – via discussions. Learning is constructing knowledge via reflection in social way and always being ready to question “paradigms”, “best practices”, “conventions” etc.
Now, I’ve mentioned the concept of Psychological Safety [7] already a few times above, coined by Amy Edmondson. She has also coined another term which is very relevant in the context of reflection and discussions – the “Fearless Organization” [8]. Your organization could become a fearless one, where no-one needs to be afraid to come to work as they are regardless of their background and where no-one needs to have reservations about voicing concerns and/or new ideas, but everyone needs to contribute to this safety by listening and supporting an open discussion culture.
The wonderful side-effect of psychological safety is that it builds inclusion which allows us all to bring our full potential to work – and this potential is often manifesting itself in the form of discussions. This inclusion is also needed to reap the benefits of diversity – something we all have in our teams – however homogenous they might seem to the surface We are all individuals and can make unique contributions for the benefit of the team, but only with safety to speak up and with a will to listen.
Reflection/Discussions and some “New” Paradigms
Let’s also look a little bit into what the latest paradigms in our industry have to offer – to understand what is bubbling under in software development teams. An interesting new paradigm is bubbling under in the agile world – the Agnostic Agile [9] movement founded by Sam Zawadi. The movement promotes common sense and orthodoxy towards frameworks such as Scrum and SAFe and emphasis on taking into consideration the specific needs of the organization. This is more demanding approach, you should not take anything for granted and adapt even closer to the organization where you work in and this can only happen via discussions. To find out the true nature and the true needs of the organization, you need to listen to all the different “voices” in the organization and reflect together in countless discussions. There is no data-source to look into or a set of rules to follow, your team and your organization need to figure it out and test different approaches – inspect and adapt.
Compassionate Coding [10], founded by April Wensel is an approach to programming which places compassion towards your teammates as the guiding principle. This means letting go of the glory of the “10x developer” or “rock-star developer” – as April calls it – status. It means embracing questions from junior developer and lauding this questioning as it surfaces important issues often hushed down in the status quo of a rock-star-led development team. It also means being compassionate in code-reviews, interviews and in developer communities – notorious for a hostile attitude towards “stupid questions” and we know that there are no such questions. What is often coined “stupid” can often be “profound”, “essential” or “paradigm questioning”. So, having better, psychologically safe discussions and reflections between peers that promote deep learning. This compassionate approach also promotes mentorship of the seniors towards juniors, again highlighting peer reflection and learning via discussions. Compassion and mentoring also support developers from under-represented groups to voice their concerns and to voice their contribution as a compassionate team is an inclusive one.
A Quick note on Discussions in the Multi-site and Remote-working Context
You can have a vivid discussion culture regardless of your team being co-located or not. In a multi-site and remote-working context discussions mean videoconferencing and chatting over IM – like Slack. Don’t be afraid of the magnitude of posts, it’s all for the benefit of the team and ultimately for the benefit of the product. IM just makes what we would call “small talk” and what would happen (in a healthy and psychologically safe environment) all the time visible. The worst you can do are comments like “let’s keep this discussion work related” or “can you take this discussion to another channel”. Sometimes, these kinds of comments are well justified, but more often they result in loss of psychological safety and people no longer being comfortable raising issues or sharing novel ideas. The magnitude of informal discussion made visible is a sign of a healthy team. A quiet team engaging only in formal discussions in designated meetings is a sign of a team in need of intervention.
Take Aways
- Talk more, more is better, informal is better than formal – lower the thresholds for asking questions and starting conversations
- There is no substitute for discussions – it’s in the essence of agile software development – and the dailies and retros will not be enough
- Informal, low-threshold discussions are needed for good teamwork and for reflection needed in learning and innovation
- A hushed and/or controlled discussion culture is a warning sign of a lack of psychological safety and should be addressed immediately, everyone in the team is responsible for an open discussion environment
- Do not wait until the end of the sprint or even to the next daily meeting if you feel your team’s approach is not optimal for fulfilling the need of a user-story
References
[1] The Scrum Guide, https://scrumguides.org/
[2] Manifesto for Agile Software Development, https://agilemanifesto.org/
[3] Hoegl, M. et al, 2004: “Interteam coordination, project commitment, and teamwork in multiteam R&D projects: a longitudinal study. Organ. Sci. 15 (1), 38–55
[4] D. Lindsjørn et al, 2016: ”Teamwork quality and project success in software development: A survey of agile development teams,” The Journal of Systems and Software 122, 274–286
[5] Socratic Dialogue, https://en.wikipedia.org/wiki/Socratic_dialogue
[6] K. Lonka: “Phenomenal Learning from Finland”, 2018, Edita Publishing
[7] A. Edmondson: ”Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly, vol. 44, no 2, s. 350-383, June 1999
[8] A. Edmondson: “The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth”, 2018, Wiley
[9] Agnostic Agile, https://agnosticagile.org/
[10] Compassionate Coding, https://compassionatecoding.com/
Our Great Team 