Now that we know the needs that need to be fulfilled to get High Performing Teams (HPTs) from my previous blog post, let’s take a look at what Scrum Masters or Agile Coaches can do.
A clear, inspiring and engaging direction or purpose set by the organization was mentioned as a success factor for HPTs. So where can we find parts of a clear vision trickle down to team level?
First and foremost, make sure that development team formation is based on the vision of the organization.This generally holds that development teams need to be formed around specific customer-focused domains (feature teams) instead of based on functional domains or based on IT components (component teams). This way, a team can focus on meeting customer-focused metrics, like number of new clients thanks to the release of a certain new feature. When it is hard for a development team to come up with these kind of metrics it is a good idea to clarify the vision for the team. One way to do this is to redefine the boundaries for the development team together with management and the Product Owner (PO). But please leave the decision on who is in the development team up to the development team.
The PO must also have a clear and inspiring product vision. And he must be able to explain how this vision ties into the vision and goals of the broader organization. Letting the PO practice an elevator pitch, explaining the product vision, is one way to help him. Another way is to help him set up performance indicators (e.g. feature usage counts) for his product.
If the company or the business domain is lacking a clear strategic vision at all, it might be a good idea to help management formulate a clear vision for at least the domain that the scrum team is working in. Make sure the team has a higher purpose than just creating some IT product.
What makes a great team is when the team norms promote a culture of psychological safety where the sum will be greater than its parts – J. Marcus
Explain to the scrum team that there is value in being a team. Not because they are together to finish a certain product, but because they have value to the organization as a unit of people working together to create happy customers.
Derived from this understanding, help the scrum team to create a team vision, like a definition of awesome, and help them distill team values from that vision. When they have a vision and shared their values, they can set out to become a true team. As inspiration for the specific team values, the Scrum values can be used. There are Focus, Openness, Courage, Commitment, and Respect.
Together with the PO, the team is now able to align team vision and team values with product vision and product goals. This is when the how and the what come together.
Feedback on collective work product
Oftentimes we find management focused on the output of development teams. As a Scrum Master it is important to teach them that it is not important to create a lot of output unless it continuously helps achieving excellent outcomes. Working software is the primary measure of progress towards the intended outcome. It is therefore important to define the intended outcome and to continuously check whether that outcome is achieved by what the development team is doing, instead of continuously checking what the output is.
Agile is all about a deep understanding that we cannot fully know what the future will hold, and being honest about that. So teach the PO to work with Minimum Valuable Products and to continuously gather feedback to adjust to a continuously changing environment.
Steer towards a situation in which the team is in a continuous feedback loop with customers, end-users, and stakeholders so they can track their progress and see the results of their collective work product. And the other way around, make sure that the customers, end-users and stakeholders are in continuous conversation with the scrum team to help them steer the product in achieving the intended outcome. One way is to make sure they are in the Sprint Reviews.
Teach the scrum team to use real-world, actual, up-to-date information to track progress towards intended outcome.
The organization should provide for a safe environment. The organization should ideally value mistakes, as long as the scrum team learns from those mistakes. Celebrating learning opportunities and holding inter-company retrospectives on mistakes is a way to express the value the organization sees in making mistakes.
At Prowareness we have made a specific point on the agenda of our monthly Company Scrum meeting. Everybody is able to share the biggest mistake he made, after which we reflect on the learning opportunity. The biggest failure is rewarded with a parking spot all for yourself (which is an actual valuable thing for us) for the duration of a whole month.
Teach the development team the value of having healthy conflicts, and also how to handle conflicts in a constructive way. This helps in achieving a psychologically safe environment for the team.
Having a catalyst in the development team can help in accelerating the growth path of the team towards having a healthy, psychologically safe environment. The catalyst is a person who is willing and able to help the coach.
During the Retrospectives help the scrum team in not only reflecting on the way they build content, but also on how they build a team. Let them express how they feel, let them share developments in their personal life, and plan fun team activities like going to a theme park together. Teach the team how to build effective working relationships.
Team members should understand that they need to work together to achieve their goals. It should be clear to every development team member what he contributes and what the other members contribute. It should also be clear to the team if and which skills, knowledge or competencies they lack to reach their goals. And they should be empowered to act on that. In the team, every team member should have a place where he can contribute to the team in the best way possible.
Help the development team in achieving this by doing workshops like Journeylines and Market of Skills, and by creating a skill matrix.
The organization should understand that engagement emerges from self-autonomy. In recognition of this, they should delegate micromanagement tasks to the scrum team. The organization should be able to create a compelling vision that enables the team to think about best solutions on how to reach that vision.
The development team is only micromanaged by the development team itself, and every team member is only micromanaged by himself. As a Scrum Master it is important to teach stakeholders and managers on which forms of interaction with the team are effective and which are not.
Celebrating success is imperative in maintaining high morale. Too often, organizations do not pay attention to achievements and this leads to demotivation and gives a message of not having important goals.
As a Scrum Master it is important to look for opportunities of celebration. Just take a small moment of thanks for small things. Just a come together with the team, having some drinks and maybe sharing a self-made cake. And make sure the PO and stakeholders are informed. For bigger stuff, organize bigger events. Did multiple teams achieve something together, they celebrate together!
It is important for the team to have a good start. During their first forming phase, it is important to pay attention to getting to know each other personally otherwise it will remain a group of people that are together for the sole purpose of creating a certain product, which has a finite period.
Apart from this good start, it is important to have shared fun experiences to get to know each other better. This is especially true for teams that are normally not physically together. As a Scrum Master, make sure this happens.
Passionate development team members might still need encouragement to hone their skills. In organizations, time pressure on delivery (output) might logically have resulted in output-focused team members that are under time pressure. Alleviating the pressure of output steering from those team members is a task for coaches and Scrum Masters.
By moving towards outcome steering, it is also important to teach the organization the importance of improving the software development capabilities. The organization should see the value of spending time on technical mastery, and the development team should be able to make this value clear. One way is to bring the scrum team together in technical-focused Refinement and giving them time to add technical items to the Product Backlog.
What you could do on a bigger scale, is to organize hackathons with multiple development teams, but make sure that the results of the hackathon are used in subsequent prototypes or even products. Nothing is so demotivating as spending 24 hours non-stop on a collective work product that will be tossed out the window when the day is over.
One way to cover a lot of topics that I mentioned above is to turn the scrum teams into mini-companies. Start a Retrospective with the notion that from next Sprint on, the team is a mini-company within the organization. Ignite this feeling by visually using the mini-company-in-a-company metaphor.
Let the scrum team come up with a company name, and a virtual physical product that they are going to build. The PO is the CEO, with the vision for the product. The development team has the vision of how to achieve that product. This metaphor can be used to foster the team building process.
The development team should do their own marketing and sales. Foster communication with the outside world, they should care for relationships outside of the team. Let them start a blog post in a company newsletter, let them gather information from stakeholders during Sprint Reviews.
Before you know it, you have a HPT and it becomes necessary to think about how to slow them down to prevent burnouts.