The ScrumMaster's Performance and Development

23 July 2013

Glen Wang
Ericsson


 
Agile is about product development, and it's also about people development. Only if both people development and product development are conducted in an Agile way can Agile be truly successful.
 
Scrum is unity of knowing and doing. Knowing is pretty much about learning, decision making, and planning. Doing is pretty much about adaption, action, and execution. Retrospective is unity of knowing and doing. Knowing is to know yourself. Doing is to adapt to the world. The ScrumMaster needs to master Scrum and include in the retrospective his/her behavior according to Scrum values, principles, rules, practices, and -- most important -- common sense. The ScrumMaster's performance and development are also examples of the unity of knowing and doing. Knowing is to understand one's performance in the past. Doing is to figure out development actions to fuel performance in the future. Unity of knowing and doing makes it a continuous improvement process. Process is attached to people and is not something independent. If the people are right, the product will be right also.
 
This model of the ScrumMaster's performance and development uses the three pillars of Scrum: inspection, adaptation, and transparency. It also uses two important concepts of Scrum: backlog and timebox. Understanding past performance is to inspect; figuring out actions for future development is to adapt; and transparency makes the ScrumMaster's performance improvement really happen, instead of being a show for the boss and the team. Without transparency, we can only get information and figure out actions on the surface, rather than touching the core. Besides the three pillars, the backlog and timebox concepts are strong weapons of Scrum. The backlog is a container that combines vision and constraints. In the backlog we put what we intend to do with consideration of reality. As a result, we can focus on what's in the backlog and forget what's not there until it draws our attention. The backlog is a box-to-box to-do list. The timebox has a similar use, but its focus is time. It boxes what's happening into a certain time. In a timebox we can focus on what's happening now and forget other things. Both the backlog and timebox create focus, one in a to-do space and the other in a time space. Let's look at the backlog and timebox for the ScrumMaster's performance and development.
 
I'm running an in-house community called Agile Tribe. Our community has open-space discussions every two to four weeks, in the rhythm of a typical sprint. We discuss topics that arise from our daily work. People who come to the meetings enjoy the open-space format and are pragmatic, contributing and learning from each other. The ScrumMaster's performance is one of the topics we have discussed. After one such discussion, we developed a backlog to facilitate the ScrumMaster's performance and development, putting it in the form of a typical user story, as shown in the table below. The guidelines for a good ScrumMaster are that, first, the ScrumMaster must master Scrum; second, he or she is a kind person.

As a I want to So that I can Score (1~5) Comments
PO Get coaching from the SM on how to develop a product backlog including ordering, definition of done, and acceptance criteria Provide the team with a transparent backlog    
PO Get coaching from the SM on how to grow, groom, and refine a backlog through emerging and evolving requirements Embrace changes into the backlog    
PO Get coaching from the SM on how to communicate product vision, value, goals, and backlog items to the team Maintain my authority as the person who is responsible for ROI    
Team Get coaching from the SM on how to do team-wise estimating, planning, and assignment Be a self-organizing team    
Team Get coaching from the SM on how to start with iterative and incremental development, and handle emerging and evolving requirements Get quick feedback and embrace changes    
Team Get coaching from the SM about Agile as human-centered; and about architecture, design, and decisions coming from a self-organizing team Be highly motivated and perform the best work    
Team Get coaching from the SM on how to build a cross-functional team and use Agile engineering practices Be technically excellent and improve continuously    
Team Get coaching from the SM on how to communicate openly, transparently, and respectfully with others to create working agreements Be a real team    
Team Get coaching from the SM on how to inspect and adapt, have the courage to discuss both the good and the bad, and reflect and replan daily and at the end of every sprint Face reality    
Team Get coaching from the SM about a sprint starting from value, vision, and goals and ending with a demo and working software Help the customer implement value    
Team Get coaching from the SM on how to respect timeboxes, including the sprint itself, planning, the daily stand-up, demo, and retrospective Maximize value from every timebox    
Team Get coaching from the SM on how to have fun in Scrum Enjoy Scrum    
Team Have effective retrospection, conducted by the SM Identify real issues and act    
Project Management Office Get clear indicators on how the project is going, through the SM's facilitation Have predictability    
ScrumMaster Read books, write articles, attend Agile conferences, and inspect the team's agility Better serve the team    
Manager Understand the SM's work Help the SM's performance and development    
 
This backlog is a live one and can grow. It depends on the team's need. It covers the ScrumMaster's services to stakeholders, including the team, PO, project manager, line manager, upper management, and anyone else concerned. The ScrumMaster and his or her manager own this backlog and solicit input from stakeholders, and grow the backlog just as a product owner grows the product backlog. It's not something perfect but something fitting the team's need, and it's dynamically raised through team interaction. The team can develop and review the backlog in a retrospective meeting or do it in a CoP (Community of Practice) meeting, which is what I'm doing. A team can inspect and adapt to find its own way to develop and use such an evaluation backlog.
 
How to use this ScrumMaster's performance and development backlog? It can be an evaluation form. The ScrumMaster can go through the backlog, giving a score and some additional comments for each story according to his/her self-awareness. The PO and team members can also evaluate the ScrumMaster using this form, to help growth of both the ScrumMaster and the team. The team can use planning poker with score of 1 to 5 to do the evaluation. The score itself is not that important; the purpose is to trigger discussion and find improvement points.
 
The timebox concept plays an important role in this process. The evaluation can be done in the rhythm of a sprint. The evaluation result is not only a score but also stands for the ScrumMaster's individual self-awareness, and it includes valid input from the PO and team members, as reflections of their interaction with the ScrumMaster. The evaluation serves as a demo/retrospective of the ScrumMaster's performance. After the evaluation, the ScrumMaster can work with his or her manager to analyze the evaluation and figure out personal development actions. This serves as planning for the ScrumMaster's performance and development. The development actions must be concrete, solid, and executable. The ScrumMaster needs to execute these actions in his or her daily work. After one day's work, the ScrumMaster can ask three questions privately: What did I do today regarding my ScrumMaster performance improvement? What will I do tomorrow? Are there any obstacles I have in the way of executing this process?
 
A good mind-set is important in this process. A good mind-set includes proactivity (change starts with me), wisdom (I believe I can succeed through this process), and kindness (the team, including the PO, ScrumMaster, and team members, support each other's goodness). The manager plays an important role to facilitate the ScrumMaster and the team in building such a mind-set. With this mind-set, the execution of the process will be smooth and concrete. Solid actions will come out naturally and be executed effectively.
 
Inspect past performance, adapt to improve future performance, and use transparency to make this a continuous improvement process. Use the backlog to create focus on improvement areas, and use timeboxing to make the improvement really happen. To inspect is to know. To adapt is to do. Transparency unites knowing and doing in the process of the ScrumMaster's performance, retrospective, and development planning.

Article Rating

Current rating: 3.7 (9 ratings)

Comments

Julien Mazloum, CSP,CSM,CSPO, 10/11/2013 10:33:09 PM
It is an interesting proposal to inspect and adapt (and therefore grow) for developing the ScrumMaster role.
Not only because of "eat your own dog food" but because it makes perfect sense by allowing to make the ScrumMaster's progress more tangible. One of the hardest things I have found out for ScrumMasters that come from a programming background is to make the progress in their new job tangible to them. Let's not forget that progress is a huge motivating factor. A ScrumMaster that loses his motivation will quit by himself.

Just a small thing: I would not call your table above backlog but something else (a scorecard? a list of SM development goals?) because you can NOT define what DONE means for any of those items while you still work on them.
Julien Mazloum, CSP,CSM,CSPO, 10/11/2013 10:43:57 PM
It is an interesting proposal to inspect and adapt (and therefore grow) for developing the ScrumMaster role.
Not only because of "eat your own dog food" but because it makes perfect sense by allowing to make the ScrumMaster's progress more tangible. One of the hardest things I have found out for ScrumMasters that come from a programming background is to make the progress in their new job tangible to them. Let's not forget that progress is a huge motivating factor. A ScrumMaster that loses his motivation will quit by himself.

Just a small thing: I would not call your table above backlog but something else (a scorecard? a list of SM development goals?) because you can NOT define what DONE means for any of those items while you still work on them.
Julien

You must Login or Signup to comment.