In this short article, I’d like to point out the benefits for team communication that come for free with Scrum as long as we’re aware of them.
Scrum is a very popular agile or lean methodology these days. There are many valid reasons for this. It’s a bit agile on rails for many teams transitioning from more classical waterfall approaches. It also allows for certain rigor and transparency around development quality for teams that don’t come from any established process other than best effort organised chaos or BEOC (my cheesy invention totally, don’t look for it elsewhere).
Scrum backlog on Taiga
Communication versus negotiation
Many other development methodologies come with techniques to sort out discrepancies arising from the project’s natural lifecycle. These techniques try to find ways to manage change and they focus on different responsibility roles and processes to cope with these inevitable small crises. In doing so, they focus too much on the negotiation scheme and miss the big picture. This negotiation over communication approach generates tons of waste over a period of time. You might have a collection of binding agreements but not a collective consensus on what the project is about and what’s needed in order to achieve its goals. This realisation will normally hit too harshly too late.
Scrum does have its own share of negotiation. For instance, which user stories from a prioritised backlog should enter a sprint is a clear negotiation effort between the Product Owner and the product team. But this intense moment of trade-off between product priorities and development convenience can only thrive in a communication-driven team effort.
For instance, which user stories from a prioritised backlog should enter a sprint is a clear negotiation effort between the Product Owner and the product team.
Scrum makes sure that when that time comes, communication across the team has already taken place. But how exactly does this flow of communication across the team happen? I answer this question below.
Scrum activities
Scrum activities are simple collective techniques to ensure that the whole team discusses individual contexts for a collective gain.
Dailies, for instance, establish a short catch-up meeting where team members share the most relevant aspects of yesterday and their aspirations for today. While doing so, they alert of any potential or clear impediments in their way. Sharing personal struggles or simply asking for help fuels effective communication and team empathy.
Sprint demos, marking the end of a sprint, are also crucial instances where some members of the team have digested and prepared a deliverable subject to validation mostly by the Product Owner but also by the team as a whole. It’s not uncommon that during a Sprint demo, questions and comments flourish and, through them, everyone achieves a better understanding of the project and a particular sprint’s success metrics. At Kaleidos (the makers of Taiga and Penpot) we encourage participation during sprint demos because for many people it represents a great opportunity to see all the pieces together for the first time in a few weeks. That’s also why we don’t suggest that sprints take longer than 4 weeks.
Retrospectives. By far, my favourite activity from Scrum. It’s the perfect intermission between a sprint demo and a sprint planning. It’s quality time the team sets aside to indulge themselves in the self-discovery process of continuous improvement. There are many flavours of retrospectives but all should have in common an open and safe space to share personal interpretations of the past sprint and ideas to make for a better sprint. Typical retrospectives focus on the very short term but we suggest teams have more strategic retrospectives every now and them. This is great to make sure you take the time to reflect on the past so far and imagine a distant future and how aligned everyone is.
It’s highly recommended that everyone is present during all these activities. Any relevant stakeholder should participate as an equal. Scrum doesn’t shine so much when relevant stakeholders (like a Product Owner or a external/internal client) don’t attend dailies or retrospectives.
Design and Code, a side note on multifunctional teams
So far, everything we’ve said here can be applied to any team, regardless of the nature of their project. However, software development teams that include designers and developers deserve some additional comment on Scrum and communication.
Long ago, Scrum was introduced by engineers and developers to enjoy some quality of life and avoid frustration. Back then (meaning 10 years ago or so), the ratio between developers and designers in a team was 15 to 1 (in full-time person units, not like in actual people count). This meant that designers saw Scrum as an imposed technique and had a hard time understanding the value of agile in general—they had no choice but to concede. That wasn’t great. I remember those days. That’s one of the main reasons we developed Taiga a few years ago, to ensure designers enjoyed the agile process too in part thanks to a tool that welcomed and praised them. No doubt, Taiga pioneered this approach and will continue to pursue design+code fruitful relationships.
Nowadays, that developer/designer average ratio is around 8 to 1 (again, full-time person units), but most importantly, design is a much more respected activity in IT. We talk about user-centred design, UX research, accessibility, design process, etc. All of which is seen very positively by developers these days. At the same time, designers have come to enjoy the agile process and Scrum in particular.
Taiga’s Scrum and Kanban boards
Scrum artefacts
Scrum, more so than KANBAN, remains the easiest onboarding experience on agile for this type of multifunctional team and the reason we strongly believe in this is because on top of the activities, Scrum has great allies in the so called “Scrum artefacts” and an inevitable consequence; Team commitment.
These artefacts are none other than the user stories, the backlog or the sprints as well as the Scrum burndown or the user story estimates. Throughout our now extensive experience with Agile in cross-domain teams featuring design and code, we have enjoyed a consistent outcome from high quality user stories. And what was behind the quality of these wonderful user stories was an active involvement from UX and UI roles in the team at the very beginning of their life cycle.
The importance that Scrum gives to the READY status for candidate user stories in a prioritised backlog, encourages early discussions and comments driven by UX/UI team members. The fact that the user story is meant to provide value to the user (or the business) feels natural for User Experience people, for instance. Developer-only teams (or developer-only Scrum practitioners) often struggled to get user stories right but the abundance of visual designers and full stack developers have dramatically increased the quality of user stories. And this has an immediate side effect, which is much less drama during Sprint planning.
You see how we closed the loop here? Earlier we said how the sprint planning process is one of the few negotiation moments in Scrum, but it’s the continuous conversation that Scrum allows for via its activities and its artefacts that makes multifunctional teams benefit the most from Scrum’s key promise; minimum waste and high predictability through sustained rhythm.
The role of Scrum tools
It may seem counterintuitive but at Kaleidos we believe that tools can’t be blamed for the success or failure of the team. And yet that’s what we do, we develop open source platforms for multifunctional teams. Why? Because we do know that certain aspects of the internal team dynamics can cause friction and waste. We also know that there are agile antipatterns at work every single day and that through our platform’s approach, we can help counteract them. Finally, we strongly believe that silo tools are ineffective and outdated ways to tackle today and our future’s challenges. We created Taiga to welcome designers into the agile world as first class citizens and we created Penpot to welcome developers into the design process as relevant stakeholders. This is a win-win scenario and we think it matters. Oh, by the way, if you’re curious about Kaleidos’ developer/designer ratio is 2 to 1.
You can sign up and try our platform with your team for free with access to all features during 30 days!
