Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo descriptionKnow our brand.
A member of the "One-club Men" is an athlete who starts and ends his career in the same team. Logically this is a great honor that makes the fans of that team have very high esteem for the athlete.
The most recent case in the world of football is that of Italian Francesco Totti, who played in Rome a whopping 25 seasons before he retired last summer.
Perhaps in these times, asking someone to spend their entire professional life in a company is almost an impossible mission, but taking it to the topic that concerns me, the question I ask myself is: should the Scrum Master be a dedicated figure in all their working day to the same team? Should you play for just one club?
The voices in this respect are somewhat discordant and, both on the internet and on the streets, we can find opinions for and against.
Some comments say not only that they should be dedicated to a single team, but that the Scrum Master does not have to be a full-time role, or even rotate between the different members of the Development team.
After a while working in this role within a Scrum team, I can provide some arguments and let the seasoned reader decide (although at the end, I will give my opinion).
The Scrum Master has many tasks to perform. In fact, with the traditional model of work used for years in Spain (hierarchical), we have naturally associated the former project manager as the figure of the Scrum Master. Nothing could be further from the truth.
The Scrum Master is a silent leader, an impediment eliminator. Sometimes, a trainer and, at other times, formed, it is the broom that sweeps away where others do not reach.
The scrum master is a born innovator, never stops: neither with the physical and / or digital planks, nor to stop improving the agile practices of the team, nor to talk about the virtues of Agilism. Oh! and has some coaching and mentoring that we can not ignore.
We could also now say what a Scrum Master is not (a tyrant or a secretary, for example), but maybe this is not the post to talk about that. So, maybe, in another post we can address the other negative views we have of the Scrum Master.
The task that seems clear to all of us is that the Scrum Master ensures that the Scrum events (Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective and Sprint) are developed correctly. It is not even to direct those events, nor to assist in many cases. Plain and simple: to ensure that they are produced and that they are carried out exactly as the guide points out.
To this we could add the guarantee that the Scrum artifacts (Product Backlog, Sprint Backlog and Increment) exist and are framed within the definition defined by the Scrum team (Definition of Ready and Definition of Done).
Around this we could talk about the boards and the information irradiators. Physical or digital. Each team can do with one or the other (even a conjunction of both), but what we do have to know is that it is something alive, updated and must change often to have its Wow effect on the team.
We often meet teams that have been doing a "Scrum but" and you have to perform a training task and eliminate "bad" interpretations. "
In addition, the teams are not always in their most productive phase (Performing), but we find teams in earlier stages (Forming, Storming, Norming) and there, the Scrum Master also has its role to play: reaching the next level and resolving conflicts. And helping to achieve self-organization, which from my experience, is the most complicated of all.
And the task of being a reflection and example of the values of SCRUM for others, the team and the organization: courage, focus, commitment, frankness and respect. It is easier said tan done!
As I said before, it is the broom where others do not reach. The Product Owner may be relatively new to Agile and in its product refinement task it needs help to split user stories or write acceptance criteria.
A good Scrum Master will help with training and teach good practices (Releases Plan, for example) to facilitate this task that will later affect the Development Team.
You can also collaborate with the team to maintain the planks or JIRA, propose innovative practices to improve performance ... A personal case has been to think and rethink the physical board of the Sprint to find the key of the best representation (to date ) for the Development team, but every Sprint we give it a new spin.
On the other hand, we say that the Scrum Master has in its tasks to form others and, therefore, they must be formed too: can someone put a stop to their training? This is a day-to-day task. If I do not have knowledge, how can I give to others?
In the end, the Scrum Master must also be up-to-date in technical matters and be knowledgeable about the business, so he must be trained in that field to help the team more.
And something we can not forget: the Scrum Master is a revolutionary! They have a vocation to change the world! Or at least, to promote change and innovation in teams and especially in organizations. This requires its space and time.
Do not you think that's enough?
Although the amount of tasks of the Scrum Master can clearly justify it being a full-time role (and that of course I do not question), the question I have sometimes raised is whether it should be in a single team. We see below some of the arguments most used to believe it to be so.
In teams with great experience someone could argue that it is not necessary. They already know Scrum perfectly and have gone to many training courses and have spent years practicing something that someone once told them was Scrum. Beware of this, there are many people who believe they use Scrum but do not do it correctly.
Assuming it is done correctly, the theory says that the Scrum Master does not have to attend some events (such as the Daily Scrum Meetings) and that is good at times, to avoid the "tutelage" of certain meetings and encourage self-organization, but I would say the opposite and that it is more true to be present at events in contrasted teams: break the chains, release the ropes ... change the dynamics and innovate!
Another argument is that in very small teams or with a product development of very short trajectory, as there is less dialogue in events, communication is more clear and fluid, less the ability of the team to build a product, a Scrum would not be necessary either. Full-time Master Maybe it is that Scrum is not the framework you need and it is worth to you simply with some small good practices of Agile.
The same with very short Sprints: the events are reduced in their duration and therefore could serve several teams, although with very short Sprints, the Increment are also less, well, more reason to have a person who helps to adapt the vision or define the product!
Or in organizations where the teams work in the same way with the same marked rules of the game and does not require so much "innovation" in practice, why could they not be in more than one team in these circumstances?
Well, because ... then what self-organization do we promote in an environment where guidelines for tools, agile practices, etc. are marked? Where no team can leave?
It is clear that there is a part of work that can be re-used in several teams (organizational change, innovation, training) and that they have enough experience and many prepared materials or has an agile community behind with a large library of resources.
In that case, maybe there are tasks that do not need much devotion, but they can never stop innovating and even less with the speed at which things happen in our world.
Also and finally, if there is a fully committed Product Owner and experts in the framework of SCRUM, the help from this figure is reduced.
If all these previous conditions have been met, then perhaps we will arrive at a day in which there is no need to change the world and we will not need a Scrum Master. But until then ... we will continue!
As I say, a full-time Scrum Master is a yes. And to the question of full dedication to a team I think that logic tells us yes, among other things because of the cost of context changes, which in practice would make us lose that Scrum Master in the path between two (or more) products and we already know that you cant take care of everything.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.