How does a Scrum Master help instil Agile values and principles in a Scrum Team?

That’s a huge question, I’ll see if I can do it justice. Firstly, let’s examine what those values are.

The Agile Values

• Individuals and interactions OVER processes and tools.
• Working software OVER comprehensive documentation.
• Customer collaboration OVER contract negotiation.
• Responding to change OVER following a plan.

The word ‘over’ in all of this is incredibly important because we want both sides of the equation, it’s just that experience demonstrates that the left-hand side of the equation is more indicative of success than the right-hand side.

That’s where the value lies.

So, we need individuals and interactions, and we need processes and tools. We just prioritise individuals and interactions in the Agile world.

So, how do we help teams start living and breathing these values?

Individuals and Interactions over Processes and Tools

If we look at this first value, interactions and interactions over processes and tools, ask yourself how your Agile journey began.

Did you get together as a team and discuss the scrum values, processes, and tools and discuss how to amplify the conversations that were already happening, creating the feedback loops that are so essential to continuous improvement?

Or did you get your hands on a tool that professed to help you roll out Agile and bring everyone together to let them know that they would now need to follow the processes of that tool and adapt as they worked?

As a scrum master and agile coach, we want it to be about people having conversations and working through creative problem-solving as a team. We want the individuals in the team to interact and engage with one another and we want the team committed to discussions around how best to solve the problem or create the product, feature or service that delivers the most value to customers.

Tools are not there to mandate behaviour; they exist to support the team in achieving their goals and objectives.

If you find yourself in an organisation that is tool driven, I would advise you to challenge that constraint. See if you can change things. If you can’t, fair enough, live to fight another day and find a compelling reason to challenge the status quo.

Figure out a way to use the tools and processes to create the conversations that your team need to be having. Create the feedback loops that are needed for continuous inspection, adaption, and improvement.

Really focus on the people.

Do they have the environment that allows them to have open, sometimes challenging conversations? Is it an environment where the tool updates act as a prompt by sending out notifications or emails rather than encouraging people to have a discussion around that element?

Customers and Developers in the same room. WTF?

Is the tool a replacement for the discussions that are necessary?

You need to help the team understand that the notifications, emails, and prompts are not sufficient. You need to help them understand that it is vital for the team to have discussions, engage, and thrash out ideas together.

Understand that a system that generates notifications and emails is not a communication tool, it is simply a tool of record.

What you want to focus on is getting the team to understand that they should talk first and write second. Have the chat and use the tool to record the conversation.

This means that over time, the team will understand that there is value in the conversations and discussions. The tool is important, as is the processes, but the real value for the team lies in their interpersonal interactions and conversations.

A good tool and process will support a great scrum team, but it won’t create one.

Working software over Comprehensive documentation

Working software or solutions or products, if you’re not in the software engineering game, is far more valuable to customers and stakeholders than comprehensive documentation.

As a scrum master or agile coach, what I would say here is that nobody wants the documentation, instead we need it to operate our products and to operate our companies effectively.

That is good governance.

Sufficient documentation is necessary. This value isn’t saying ‘no documentation’ it just focuses on producing working stuff as a priority over comprehensive and exhaustive documentation.

As a former software developer, I completely understand the desire to produce zero documentation.

Management versus Leadership

It isn’t fun, it is often tedious and a pain in the butt, but it is necessary.

So, we need to have an understanding, often through the definition of done, of what is necessary. What do we need to do? What do we need to produce? What is sufficient?

As the organisation grows and there are increasing levels of bureaucracy, the demand for increased and comprehensive documentation tends to grow. Sometimes, it’s a senior manager who demands these elements and at other times, it’s simply fed through the grapevine.

You need to challenge this, respectfully but assertively. You need to strip that excess away.

What is the minimum that you need?

Have conversations with the people who are requesting these reports and comprehensive documentation. Ask them why they need this? Ask them what the benefit of the excess documentation is? What is the outcome they are looking for from the documentation that they are requesting?

Their response may be valid, in which case, great, it goes into the ‘necessary’ part.

It may not be valid. They may simply be in a position of authority where they can ask for things and simply expect that it is delivered. They may simply be focused on their own wants and expectations without having any idea of how that request impacts the team and their productivity.

So, you need to work with those individuals and help them navigate what an acceptable answer or request might be. You’re not going to win every battle, especially on day one, but over time you’re going to make inroads and help people understand what sufficient looks like.

Covid Hacks – Hiring

Understand that customers don’t buy a product for the paperwork. They buy a fridge because they want to keep perishables fresh and cold. Yes, they require a certain amount of documentation to be able to use the fridge and set it up correctly, but they don’t require comprehensive documentation filled with elements and information that are of no value or use to them.

The paperwork doesn’t provide the value to the customer. The working product does.

Get people focused on creating the best, working product and work out what sufficient documentation is to support that product. Eliminate anything that is unnecessary.

Customer Collaboration over Contract Negotiation

Contracts are necessary in business. They are sound and sensible business practice, but they do not predict success. Contracts are there for when things go wrong.

Contracts need to be in place, and we need them to set the scene, but we want to avoid using them.

Contracts won’t help you build a great product. What we need to do is work directly with that customer to understand their evolving needs over time.

As a scrum master, you often work with a product owner or a product stakeholder. They act as a proxy for that customer and represent the customer voice in the organisation. Sometimes you are lucky, and you get to work with the customer directly.

You need to ensure that the product owner and product stakeholders work closely with the developers and where possible, also encourage them to work directly with the customers. Your role is to facilitate this and close the gap between the developers and customers as much as possible.

You want the whole development team having open, continuous conversations with the product owners, product stakeholders and customers to really understand what the need is, to understand what problems need solving.

If you are working with the product owner, that is great, but you want to ensure that you are making the product owner aware that they are a proxy for the customer. You want them to understand the importance of the customer that they represent and to ensure that they have frequent and continuous conversations with the developers.

You also want to ensure that the developers have access to customers directly and can have open, productive conversations with those customers, in conjunction with the product owner and product stakeholders.

You’re not stepping on toes, you are simply reminding the product owner that it is far better for the team to engage directly with the customer rather than any intermediary, regardless of how skilled and experienced they are as a product owner.

Every person who gets inserted into the chain between the developer and the customer is an opportunity for a miscommunication, a misunderstanding, and potentially even leading to the team solving the wrong problem at the wrong time.

As a scrum master, you want to develop relationships with customers because when things do go wrong, the customer is on your side. They have a relationship with you, and they understand that your focus has been on trying to help them get the best possible product in each sprint.

They will give you the benefit of the doubt in circumstances where things go wrong.

They aren’t going to go back to the contract and try and work out who is at fault. Instead, they will see that you’ve put your best foot forward but the solution simply isn’t possible, and their focus will turn to how you can move forward given that X isn’t able to be delivered.

They will join that conversation, openly and willingly, and we don’t have lawyers involved.

Because they have been a part of the journey, and because they have collaborated with the team, they are in a far more inclusive position and trust the team.

Responding to change over Following a plan

Following a plan regardless of what you have learned on that journey is just plain daft.

Having a plan and following that plan whilst it is valid is useful because it’s a great way of aligning everybody. What we really want the team to understand is that the plan is transient. It is only going to be right for a short period of time.

As soon as we recognise that the plan is no longer right, we need to adapt and respond.

We need to do something different based on what we’ve learned, which may involve updating the plan. In fact, if the plan is a useful tool and its easy to update, you can do that regularly.

If it’s difficult to update or we need to rely on somebody else to do that, its going to fall by the wayside very quickly.

As a scrum master, you’re helping the team understand that as they build, create, research, etc. we are going to uncover new solutions and discover better ways of doing things. We are going to break assumptions, based on what we have learned, and in doing so the plan is going to become wrong.

You have a choice at that point.

You can stick to the plan and do what you said you would do, regardless of whether that continues to be the right thing for the customer, or you can make the necessary changes and ultimately build or create something of greater value to the customer.

You want to help your team understand that the plan they created is great, but it was created with what they knew and understood at the time. As things evolve and new information comes to light, it is necessary to make informed decisions based on that evidence and adapt the plan.

So, as a scrum master and agile coach, we’re looking to bring these 4 values alive in each team we work with. We need to work with both sides of the equation, but we want to ensure that we are simply doing ‘enough’ of the right-hand side and optimising the left-hand side to create value for our customers.

If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.

If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course page.

If you have several years’ experience as a scrum master and want to both validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master course page.

If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.

If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction To Coaching course page.

For more information on John McFadyen, visit https://www.growingscrummasters.com or connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/