Scrum master: promoter of the theory, practices, rules, and values of scrum.
Scrum in a company
Companies didn’t want to use scrum, it was never the goal. Companies try to figure out how to build the right thing at the right time for their customers. They are after customer satisfaction but it turned out that predefining the release dates, trying to land on predetermined targets, defining previous big designs upfront,... it used to work, but now, simply it does not work anymore.
Successful companies are turning into empiricism, observing behaviours and outcomes, inspecting what is going on and making frequent adaptations. Scrum is the only framework out there that lets them do that, that is why they want to use it.
In scrum we learn by doing. We do not prepare super defined roadmaps for the next year(s) and force us to stick to them. We use the feedback we got from our last movement and use it to improve and maximize the result of the next one. Is by doing the work that we understand the work we need to do. Throw away the playbooks, do a little bit, gather feedback and figure out if what you are building is right.
Implementing scrum is a huge investment, it is very expensive to hire an agile coach, some scrum masters, prepare events, prepare the people,… we spent so much money doing this that it must be a competitive advantage for the organisation, otherwise it is a waste of time and money. Self-organising teams, cross-functional teams, empowered product owners, all these things get us to that competitive advantage, so the investment in the scrum adoption is worth it, only when done right of course...
Mastering scrum
Being proficient at implementing scrum is no easy task. If we compare it to chess, the rules of chess are quite simple and basic, you can learn them in just one afternoon, but becoming a great master, requires several years and in most cases a lifetime. Similarly, you can read the 17 pages of the scrum guide in one sit, if you have not done it, do it now, I’ll wait.
Once you read it, you can start right after, prepare the first events and artifacts for your team, distribute the roles, but the very first moment you start to apply scrum, impediments happen. Friction appears everywhere because the organisation is not used to work in that way, it is something very disruptive. It takes a long time to learn how to leverage agility and empiricism in a way that it is useful for individuals, teams and the company itself.
You may need a while to unravel organisational dysfunction, it takes a long while to change the mindsets from command and control to servant leadership, basically, it takes years to master how to change the DNA of a company. The challenge is everywhere else but the scrum framework itself.
The scrum master role
The scrum master is the enabler of the team to succeed, remove impediments and serve the team. Any scrum master should look after these three statements:
- Devotion to the team. Deep care of the team, want them to be as successful as possible.
- Level up people. Help to get promote and elevate each one of them, even in their careers.
- Remove organizational impediments. Zero tolerance for anything that is holding the team back.
The person that holds the role of scrum master should impact the scrum team, help the team to deliver, empower each one of the team members and remove any organizational issues. This person should never fulfill the PO’s role nor tell the developers what to do. Also do not neglect the organisation problems avoiding difficult conversations with leadership or HR. With the COVID-19 situation and all the remote working, these organizational problems only get amplified, but now the impact is 10x.
The scrum master is the bridge between the team and everybody else, a bridge that is constantly shrinking until it completely disappears. The duty here is to connect people, not being a proxy, put the stakeholders and the dev team together, not place themselves in the middle.
A scrum master does not keep the backlog up to date, a scrum master does not baby sit the dev team. In scrum, the teams have to keep their progress visible and transparent so we can keep them out of the status meetings with managers, that is the deal.
Always fulfill the three levels of service: P.O., Dev team and organisation, in a way that empowers others, not commanding and controlling. Do not take the power and influence of the role to command and control other people.
The scrum master only makes sure that the scrum events happen and is only facilitating when needed. They are not the center of attention, it is not about them, it is about everybody else in the meeting. For instance, daily meetings? Totally optional, the scrum master just has to make sure that it takes place and they should only facilitate when the team still does not know how to do it.
Make everybody understand the scrum values
It is very easy to turn scrum into a process, in order to avoid making people understand that this is a framework, a human practice, and leadership should go first. People will crush any scrum implementation if the values are not followed. We need:
- Focus: to tackle fewer things at once, but getting things done.
- Courage: to speak to the power, to managers and leaders. to say a stakeholder “no” or to a customer “not yet”.
- Openness: to new ideas, to be wrong, to diversity, to inclusion,...
- Commitment: to give the 100% of ourselves, but never to a scope, big misunderstanding here.
- Respect: all things above must be done in a respectful way, otherwise everything tears apart.
Teach the culture because this is what is really important.
Prepare the development team
The dev team is a self-organized and cross functional group of people that is capable of delivering a product. The team can build and ship an increment of the software on their own without depending on any other team to do anything for them. We implement scrum in an organisation to use it as a competitive advantage, part of that competitive advantage is time to market, being able to generate a new idea and place it into the world in hours, if not minutes, is game changing. If we have to wait for decisions, if we have to wait for permissions, wait for all these proxies,... we lose time and money. We are giving up this competitive advantage by organising us in bad ways. When setting a new scrum team, we expect a good return on that investment.
Engineering managers should clear impediments, take care of HR duties, but it is not their task to tell the team how to do their work anymore. In scrum, we empower the dev team to figure out how best to do their work, we trust the team to decide how to do their work, the team is accountable to get the job done, accountable to deliver and they have to decide how to get there passing all the constraints along the way.
From a scrum perspective, if you have an engineer manager, people manager, lead architect,... is up to the organisation, but the team is fully empowered in any case to decide how to do their job. If they find obstacles, they can go to their manager to help them or to clear the way, but in any case the manager/lead role is only to help the teams, not command and control them.
Scrum does not recognize titles between dev team members, in a self organized team, a tech lead fades away. There is not one voice louder than another, we want a highly collaborative environment, respect, rely on others and help each other,... A scrum master should detect this and correct it: Go to HR and make them understand that by creating hierarchies inside the teams, they are killing the team self organization, they are causing issues to the team culture. For sure they can compensate these more experienced people in different ways.
Truly cross functional self organizing teams with strong ownership, always will find ways to sort things out.
Teach the product owner
A scrum master has to make the product owner understand they have to maximize the value of the dev team, that they have to protect the investment made by the organisation and look after the 3 Vs:
- Vision: The impact of our project in the world with our effort.
- Value: Define what value actually means,
- Validation: Accountable to check if what we deliver reached the value expected.
Usually product owners are very busy persons, they have to talk to customers, perform a/b tests, perform market research, have constant meetings with leadership and managers,… They are here to make sure that what we are building is actually what people need and want. They have to define how winning looks like.
In the scrum guide it says: “The Product Owner is one person, not a committee”. We want just one voice for one product, a person that is able to make decisions tactically, strategically and even financially without waiting for permission. When we have a proxy product owner, it only leads to waste of time, waste of work, and if the needs are not communicated properly to the head product owner, this person is not going to make the appropriate decision. Many problems will come up. This doesn’t mean that the P.O. cannot get any help, a person inside the dev team could be accountable for the value of a piece of product in front of the rest of the team.
The cohesion is going well in the team when a PO can defer a question from a stakeholder to anybody else in the dev team. It is a really good sign that the relationship is working. The PO trusts the dev team, and the dev team show that they truly understand what they are doing. Just a little thing, but very significative.
Protect the backlog
POs express the value and vision in the backlog, holding all the things we could do to match the product vision, sorted by value of what we could do. In english, by definition, priority is singular. Having more than one priority invalidates the first one. In a scrum team we only have one priority and this is the sprint goal. The backlog is not sorted by priority, the backlog is sorted by amount of value, notice the big difference. In the daily we inspect our progress towards the sprint goal, and if necessary we perform some adaptations with the things we learnt along the way. We are in a complex domain, and we are learning about it constantly.
Prevent backlog from growing too big, set a limit time to live for a story, something like 3, 4 or 6 months, depending on your project, and delete everything that goes beyond that. If a story never got enough value during this time, most probably is never going to come, and if it does, the context would have completely changed, so you’d need to rewrite the whole thing again. Don’t worry about deleting stories, if it was important, it will come back from the feedback of your customers.
Beware of changing scrum
Be careful and be sure that you adapt the company to scrum and not scrum to the company. When scrum has to change, it is because some organisational dysfunction, rather than changing scrum, change the way your company works. Leave the framework alone! There is a lot of space to be creative outside the boundaries of scrum, between the events, artifacts and roles, but do not change the framework itself.
Measuring success in scrum
We know whether we adopted scrum successfully when we can answer affirmatively to the question “Do we deliver high quality products that delight your customers?” That is the only measure that it counts. Do not focus on the figures of the scrum master or the agile coach, if your company cannot ship an increment of the product at the end of the sprint, it is a clear sign of failure.
The scrum master is an advocate of the scrum process, values and principles. Clearing the way far beyond the process: remove organizational obstacles, create a cozy work environment, ensure communication with and within the team, promote collaboration,... a servant-leader to the team, to protect it and to push it forward. A scrum master can only succeed if the whole team succeeds. The name master is not given by chance, we consider this person an expert of scrum, and as an expert, we expect from that person to help and coach any member of the team in need.
Top comments (5)
Good article! In regards to the "Beware of changing scrum" section, I would that Scrum will not fix your org's problems ,but it will reveal those problems.
Thanks for your comment, I couldn't agree more! Agile doesn't solve problems, agile expose problems and it is up to you how to react to it. If you don't do anything, if you dont take that feedback, why you are implementing scrum at all?
Hi Josep,
Does scrum master attend the daily scrum meeting? And Why?
The Scrum master only needs to make sure that the meeting takes place, but not necessarely attend. He can facilitate at the beginning if the members don't know how to do it: what i did yesterday, what i am going to do today and spot any blockers... Also foster the collaboration between members, and preventing that it becomes in a simple status report for a manager.
Why? Because a Scrum Master is not an administrative assistant of the process, "the person that just" creates the meetings or updates the board. The SM is a transitional figure, it helps the organization to swap from traditional planned, cascade, top-down organization,... to agile ogranizations with product teams. The SM is a promoter of agile/scrum and as the team improves, his impact fades away until it completely disappears because you already have a high-performant product team in the organization. Everything works well.
Thank you for asking! :)