Three things I learnt being a scrum master
Introduction
I am very happy to have had the opportunity to work in the Agile world for almost 4 years, that have been fantastic and challenging.
Being a Scrum master is an invaluable experience and makes you understand and reflect a lot about company processes and software development in general.
It is very hard to discover and address disfunctionalities in teams’ processes. In fact, disfunctionalities are often sneaky. Metrics and surveys can help you but you need to develop an insight to recognize them and this helps you improve a lot as person and professional.
I decided to share with you three thoughts I noted down in these years.
1. Training is not enough, make it real by being assertive (when necessary)
In these four years I did tons of training. Prepared tons of presentations on the various agile practices and artifacts: Kanban, Scrum, backlog and backlog refinement, pair programming are only examples.
One thing I learnt is that while training on agile is valuable, practice is more valuable. The capacity toward making practices real in day to day life is fundamental in the scrum master profession. In order to do that there are two different and antithetic approaches:
- wait that a practice emerges in the team
- be assertive and effectively contribute by pushing for the application toward some beneficial practices.
Being able to find the right balance between these two approaches is a fundamental key in a scrum master role. In a perfect world the Scrum master would always choose the first approach. But in the real world, this is not always feasible. For example, there could be situations where it is not possible to wait until the team becomes mature enough to adopt a practice. On these occasions, in my honest opinion, is when the Scrum master needs to be assertive.
2. If you want to go with Kanban, start with Scrum
I am assuming you are familiar with the Tuckman’s stages of group development here.
It is harder to start directly with Kanban than starting with Scrum and transitioning to Kanban. In fact, Kanban requires much more discipline from the team than scrum. Pulling stories at the right time, limiting the amount of work-in-progress items, are very challenging tasks, even for a very small group of people. This makes Kanban more functional in the teams that are in the norming or performing phase or however not at their beginning. While scrum being more prescriptive, is perfect for a team in the forming and storming phase.
It is a good idea to start with Scrum and transition smoothly to Kanban when you feel the team is ready, or rather when the team is entering in the norming/performing phase. There are many indicators a team is transitioning toward the norming/performing phase:
- stability in practices adopted
- stability in team composition
- continuous success of sprints
- self-organization in main scrum ceremonies
- stability in velocity and throughput.
3. Scrum application outside the software world often is not clear
While scrum is supposed to be an universal framework, in the sense it should be applicable outside of software world, this application is not always immediately clear.
In Hotels.com we give training on Agile to very different functions and we encountered difficulties in recognizing a way to apply scrum to certain realities outside of technology. For example there is not so much literature on how backlog items should be documented. Neither is clear how to manage realities where we have mostly personal work rather than team work.
Conclusion
I had four challenging years as Scrum master and this opportunity make me grow as person as well as IT professional. During these years I had the opportunity to reflect on some aspect of the Scrum master practices.
Particularly I discovered that the Scrum master need to be assertive and effectively contribute by pushing for the application toward some beneficial practices when necessary. The natural emergence of all the team practices is simply a Scrum myth.
I, furthermore, think that Starting directly with Kanban for a new team can be counterproductive. My suggestion here is to evaluate Scrum as bootstrap for Kanban.
The last point: the fact that Scrum universality (its application outside of IT projects) is not crystal clear. Under this point of view a great community effort to make Scrum more accessible is needed.
