Agility needs diversity

Let’s get agile! Different people have different hopes for this change to the process model – for instance, some are hoping short feedback cycles will minimise indirect risk, some want more innovation for users and others would like to create a better and more productive working environment. If this transition is to succeed, then it will take a different mindset and team members will need more decision-making power. Diversity also plays a crucial role in meeting these complex and ever-changing challenges – which I think fits perfectly with the first point in the agile manifesto: ‘individuals and interactions over processes and tools’. In this post, I’d like to use a simplified model to explain what this means and how agile practices help a diverse team solve complex problems.

Resilience is a bridge between diversity and performance

An agile approach is suitable for solving complex problems. ‘Complex’ means that the requirements or the technical structure are not fully known at the start of the project. The benefits of agility come from delivering and evaluating the product early on. Agility is a constant learning process, where the experience collected from previously delivered versions is incorporated into a new solution.

Resilience is the ability to overcome these challenges and to use them as an opportunity to evolve. It is an absolute must for an agile team. If a team is to build its resilience, it needs a range of expertise and perspectives (diversity), a safe environment (psychological safety) and the team members to have a sense of autonomy and responsibility (empowerment). A resilient team then performs by solving complex problems (ambitious goals).

The model is also used in this way or in a similar way to this to research agile methods. I’ll just call it the ‘resilience model’ here.

Case study: introducing Scrum in a waterfall context

I’d like to give you a brief example that shows how introducing Scrum does not automatically lead to agility. Let’s imagine a fictitious team of developers who have previously worked following a given set of specifications. The project manager wants to change the process model to Scrum, so all of the team members complete a scrum training course. One developer is chosen to be the Scrum Master. The role of the product owner is assumed by someone from the specialist department.

Things are a little bumpy at first, which was to be expected. After three months, however, the team has settled back in and is back to performing well. This is measured by the percentage of progress compared to the original specifications. The project manager asks how things went during the annual review meeting. He finds out that the team has designated an experienced developer as the technical product owner. Their task in the team is to divide the user stories into tasks in a way that causes as few technical difficulties and requires as little additional communication as possible. Who takes on which task and how to create as few merge conflicts as possible during the implementation is then only determined when they plan the sprint.

For the user stories, the product owner has slipped into the habit of taking what used to be the requirements specification and rewriting it into user stories. The Scrum Master leads the scrum meetings, but otherwise they have a lot of time to focus on development. The question of when the back log has to be completely cleared once came up during a retro. The scrum master answered by explained that those types of deadlines don’t exist anymore. The project manager is a bit surprised about the implementation of Scrum, but is satisfied.

This example shows how Scrum was introduced as a solution without thinking about the actual problem that is trying to be solved. Perhaps the motivation was that users haven’t had much benefit from the changes so far and therefore their feedback should be integrated. Or maybe it was unclear whether the technical architecture was actually suitable for the described system, which is why they wanted to create functional temporary versions. Or was it just the trend? In the example, ‘Scrum’ was introduced and yet work continued according to the waterfall model: requirements already existed in the form of a specification sheet, which had to be implemented as efficiently as possible. Agility is about empowering a team to solve a complex problem, not magically making a team faster or better. You can, of course, use Scrum to implement a specification, but that doesn’t mean it’s necessarily the right tool.

Diversity

The simplest model for diversity has two categories: job-relevant diversity (specialist knowledge, experience or training, for instance) and background diversity (gender, migration background or disabilities, for instance).

Job-relevant diversity is important in bringing a wide range of specialist knowledge together. If the only tool you have available to you is a hammer, then of course you’re going to see a nail in every problem. For instance, if an enthusiastic development team with a preference for a particular programming language wants to solve a problem, the solution is very likely to be a piece of software written in that programming language – regardless of whether there might be other, better solutions. This means that diversity expands the scope of possible solutions. In the case study situation, for example, it would have been useful to bring some of the stakeholders directly into the team, rather than continuing with a pure, unchanged development team so that they could contribute and present their point of view.

Background diversity also plays an important role. It has a positive influence on communication and the exchange of information within the team. It is well established that this strengthens the resilience of the team in general. Plus, diverse backgrounds and the points of views that come with them are a breeding ground for new ideas, making them important for innovation. Apart from this utilitarian, practically oriented view, diversity also represents a value in itself.

It’s sometimes said among software architects that it’d be better ‘if everyone thought in the same way’ because then there wouldn’t be any difficulties and communication problems. Then everything would be so much easier. There is always a touch of ‘if everyone thought like me...’ lingering behind this statement. But even groups of like-minded people have their limits – they can’t actually read each other’s minds. Communication is the be-all and end-all. Wanting everyone to think, or believing that they should think, exactly like you is detrimental to agile teams, as the majority opinion is no longer critically questioned and other, sometimes better, solutions are not even considered. Diversity, on the other hand, leads to different perspectives, ideas and opinions coming together. The result of this is that constructive conflicts arise early on and can be resolved. Homogeneity, on the other hand, only postpones potential conflicts, but at some point in the course of development, these inevitable problems will emerge and end up being very costly.

Psychological safety

If a team is to uncover conflicts and find solutions, it needs an environment in which all of the members of that team can contribute their perspective to be able to question the structures that have developed. A well-known model for this sort of safe space is divided into four levels:

• 1. The security of being accepted as a human being (inclusion).
• 2. The security of being able to learn (by asking questions or receiving feedback, for instance).
• 3. The security of being able to contribute something of your own.
• 4. The security of being able to question the status quo and discuss opinions.

This is of course an ideal – but it should at least be strived for, even outside the construct of agile working. If a team is large enough, then an anonymous survey can be a way to explore how psychological safety is perceived and how it can be improved. Psychological safety promotes the positive effects of background diversity and mitigates any negative effects.

Psychological safety also supports empowerment, that is, the ability to work with a sense of autonomy and responsibility and to be able to perceive, make the most of and expand your own creative scope. This includes, for example, that I as a developer want to understand the specialist department so I can create added value for the users. I want to learn and expand my skills to meet the new requirements. I want to become more independent and grow my network so I can communicate directly instead of going through several other people. Let’s bring it back to the case study: Breaking down user stories into small-scale, technical tasks prevents developers from engaging with the use case and understanding how they contribute to it.

Agile practices from Scrum

To make it concrete, I want to take some Scrum practices and map them to the resilience model. This should make it clear how agile methods contribute to resilience and thus to agile working. Scrum entails the following practices, for example:

• Retrospective: the review of the past sprint to create a plan for improvement. The Scrum Master creates a space in which open and positive discussion can take place. Since the entire motivation behind this is psychological safety, the Vegas rule – ‘what happens in Vegas, stays in Vegas’ – also applies to this discussion. Everything that is discussed in the retrospective is confidential and remains between the participants.
• Daily: daily, short stand-up meetings should improve communication and bring difficulties to the surface. This practice focuses on empowerment in particular, as regular discussions make all of the team aware of what is going on and allows them to support each other when they encounter obstacles.
• Sprints and reviews: developing and delivering the product iteratively allows the interim results to be evaluated directly in the reviews. This is a basic requirement for resilience, as it allows the explicit and implicit assumptions to be tested.
• User story: ambitious goals are needed to turn resilience into performance. These are expressed in the form of user stories that are designed to add value to the users. A user story captures the complexity of a particular scenario from start to finish, not just individual technical steps. This principle that user stories make team members understand the background of the use case is also part of empowerment.

Taken together, these agile practices cover all the aspects of generating performance from diversity according to the resilience model. Other practices can also be added to complement the model, such as pair programming, to improve knowledge transfer between team members. But if you take out practices – retros, for instance – then you can see a gap in psychological safety.

Conclusion

In summary, I would like to emphasise that diversity and psychological safety are crucial factors for team resilience and thus for performance in agile contexts. Agility means constantly reacting to new requirements and learning from experience. Psychological safety provides the right environment for diversity and empowerment to lead the way to this team resilience. It is through resilience that ambitious goals are transformed into constructive conflicts and ultimately into solutions.

Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.