Three Areas of Improvement to Increase Your Teams Agility

Inspect and adapt are vital principles regardless of the flavour of agile you're using, be it Scrum, SAFe, or anything in between. I know that when I’m a few weeks into working with a new organisation, I often feel overwhelmed by the amount of areas for improvement that I see. It can be challenging to know where to start and which areas with plenty of room for improvement will have a lower impact and, therefore, are worth considering as a lower priority. Over the years, I’ve realised that prioritising some areas over others will support improvement in those other areas over time. The first thing I like to look at is the agile mindset. Are people aware of the values and principles they should be guided by in their work? After that, I look in tandem at the processes of the teams and the value of the product. By improving these three key areas, you, too, can help increase your team’s and organisation’s agility.

Agile Mindset

Developing in complex environments means that there are few rules available to follow. Therefore, the values and principles that guide agile practitioners need to be kept front of mind so that we can use them as a guiding beacon when making decisions. I like to check in early on when engaging with a team to find out what their level of knowledge and understanding of the Agile Manifesto, Scrum Guide, and Lean Thinking is.

It continues to surprise me how many people in agile organisations haven’t read any of these foundational documents. I don’t expect anyone other than us agile nerds to have a deep understanding or memorise the Agile Manifesto. However, if you’ve been working in an agile environment for more than five minutes, I don’t expect you to be under the illusion that there’s no documentation involved in agile ways of working.

Back when I was still a software developer, I worked in some truly terrible “Scrum” implementations. I was often hired as a developer who would help to bring agile into the organisation. As such, other developers would come to me to talk about their thoughts and feelings about agile. Many told me they just didn’t get why there was such a buzz about Scum and Agile in the industry, as their experience of it was not a happy one. To me, it was so obvious that we weren’t working in a Scrum or Agile environment, and I would talk to my colleagues about which of our practices did and didn’t align.

I’ve previously written about a retrospective format based on the Agile Manifesto and how to create a Team Charter based on the Scrum Values. These are effective ways of increasing the visibility of Scrum and Agile whilst also achieving something agile / Scrum Teams should already be engaging in. I hate doing anything that only accomplishes one thing, so in my mind, these are perfect meeting structures. After all, maximising the amount of work not done is one of the Agile Principles.

Team Processes

The Scrum Guide gives guidance around roles, artefacts, and events in so much as it tells you what the purpose of each of these is and what you should hope to achieve with each of them. However, it doesn’t dictate how you get from one to the other. The Scrum Master should facilitate stakeholder engagement with the Scrum Team, but there are no instructions about how the Scrum Master can achieve it. Scrum is a framework, after all. This leaves a lot of freedom and flexibility for the Scrum Team to decide how to do their work based on their unique experiences and environment. However, without guidance or reflection, teams can easily fall into anti-patterns without realising it. As with most things, strengths are weaknesses too.

There are two techniques that I use to evaluate the effectiveness of team processes. The first is to look at how each of the Scrum Events are being implemented (and sometimes even if they’re being implemented) and assess whether the three pillars of empiricism as defined by the Scrum Guide are present: transparency, inspection, and adaptation. If anyone can’t or won’t be transparent in any of these meetings, that is likely to be symptomatic of a lack of psychological safety. Trying to get to the root of why and building up the level of safety can take time and is crucial to achieving the other two pillars. Once transparency has been achieved, a team can engage in reflective practices that allow for the inspection of their processes. In turn, both of these pillars support the ability to improve through the final pillar, adaptation.

The second technique I use is to watch how conversations are affected by how they implement their processes. Are the conversations collaborative and constructive, or combative and siloed? If the former, the team is on the right track, even if the Scrum Events aren’t achieving their goals. However, if the latter, then the cohesion of the Scrum Team needs to be looked at. I once worked with a team where everyone talked over each other. I gave them a talking token so that only the person holding it had the right to speak. In the first meeting we used it, one person jumped over a table to snatch it out of another’s hands so they could talk. It was such a visual and visceral moment that the team could no longer deny that the way they conversed lacked respect for each other. Although it took a little longer to stop talking over each other, the team knew they had to work at it, put the effort in, and succeeded.

Product Value

This feels like it should be of the highest priority. After all, what is the point of working in a team if not to create a valuable product for our customers and users? However, I repeatedly find teams where not even the Product Owner shows the attention to value that agile demands. (To be fair, it’s often not the PO’s fault; see my love letter to the role to understand why that may be.) One of the first things I ask of a PO is to see their product vision or goal. I don’t think I’ve ever had a positive response to this request. I’m expecting to see something that explains how delivering this product will contribute to the organisation’s strategic goals, but often no one at the team level knows or understands what those goals are either. Creating and communicating both of these things will make a huge difference to your agility.

Another way to improve your product’s value is to ensure you understand your users and customers. Which of these two groups is more significant to you will depend on what your organisational and product goals are. There are many tools to create personas to represent subsets of these groups, and my personal favourite is the empathy map. There are plenty of templates on the web, most of which have walkthroughs of how to complete them, so even a novice should be able to create a basic version.

All agile people love metrics. We try to be as empirical as possible in our work, so this is hardly surprising. Consider how you are measuring the value your product is delivering, and remember, you get what you measure. Again, this is going to be heavily linked to your organisational goals. If you care about revenue generation, then measure customer profitability. If you care about engagement, then measure daily active users. It doesn’t really matter how you measure value as much as it matters that you are measuring value.

Just Start

There are many ways you can improve your team’s agility; these are my preferred starting points and by no means a definitive list. You will know your own context better than anyone entering your organisation, and I’m sure you already have a few ideas of where improvements can be made. The important thing about continuous improvement is that you just start your journey, and by starting, you will instantly increase the agility of your team and your organisation.