Thursday, January 26, 2017

Why Rotating the Scrum Master Role Works for Us



Conventional wisdom has it that rotating the scrum master position should not be a permanent practice.  Mike Cohn has an interesting blog entry from a few years ago, which supports this wisdom, while presenting both sides of the argument. I heartily recommend looking at that blog, including the insightful comments from readers. Based on my experience with our scrum team, and observations from others, I would suggest that creating a “permanent” scrum master is not necessarily the best choice, and doing so closes off some possibilities for getting the most out of agile methods.

Our team is not an immature one. In its current form, it has existed for over 4 years, which periodical personnel changes over the time. Our first scrum master was in the role for about 2 years, and she helped us to improve.  Since then we have put the position on a 3-6 month rotation.

Here are two assumptions that need to be re-examined.
  1. This may be sacrilege, but I’ll say it: Very few people want to be scrum master. You could hire someone off the street whose ambition is to be a scrum master (see job postings, there are many), but in most cases, the scrum master is chosen from the ranks of existing employees. If you have a team full of professionals who are moving to scrum, people want to continue practicing their profession, not doing the things that the scrum master role asks you to do. So what happens? The manager assigns scrum master duties to the most junior person, or the person who otherwise draws the short straw. Only in edge cases will a team already have a person who desires to develop into an agile coach, which they perceive (justly) to take them out of their current career path.
  2. The coaching aspect of scrum mastery is, IMO, overrated. Our team is full of coaches. We coach formally and informally all the time, in structured and opportunistic settings. By having everyone be the scrum master over time, the scrum master merely continues to support a coaching culture within and around our team

 By rotating the role every so often, our team found these benefits.
  1. The scrum master got better. Every person who has entered the role, went in kicking and screaming, and came out the other end a better team member. Some develop an appreciation for what everyone on the team contributes, some stepped forward as a leader instead of remaining as a wallflower. Some learned to see the benefits of scrum more clearly, or  out as a more mature agilist. The change has been different or every person.
  2. The team got better. The top focus of our scrum masters has been to improve our internal processes. He or she leads the team retro, and facilitates the commitments to improve, which often turn into stories. By getting fresh blood into the role of facilitating continuous improvement, we see innovation all the time. One scrum master will come up with a new structure for our retros, another will come up with better charts or metrics to present team performance improvement. A third will explore and incubate deeper understanding of our planning tool. Another might beat the team over the head with the rules of scrum, making sure that we don’t follow (or break) any of the rules without a sound, consensus-driven reason.  Everyone has their own view on how the job should be done, and if they have that good intent, if their heart is in the right place, we give them time and space to do so.

Listen, I admire Mike Cohn and many of the other agile/scrum experts. Without them, it would have taken me much longer to get up to speed on how my team and I could, as Mike would say, “succeed with agile.” However, I am wary of agile gurus telling us what we should or shouldn’t do, which rules can be broken and which ones must be followed. In the case of Scrum, I am in favor of teams starting out going by the book (that is, the rules of the game as described in The ScrumGuide), but over time, teams should feel free to discard the rules that don’t serve them and introduce new processes that support their ongoing efforts to collaborate better.

Monday, January 16, 2017

My Upcoming Presentation at ISPI's THE Performance Improvement Conference



Great News: The International Society for Performance Improvement (ISPI) has accepted my submission, Getting Started with Agile, and I will present it at THE Performance Improvement Conference 2017, which will take place April 28 - May 2 in beautiful Montreal, Quebec. Here is an overview of what to expect.

Agile was invented by and for software makers. The Agile Manifesto and Principles mention 'software' five times and all other forms of work output zero times. Non-software people are increasingly interested in the benefits of agile, such as adaptability to change and more consistent delivery of value to customers. But, how do you practice agile software development methods when you're not developing software? There is so much to consider, but how do you get started?

I will address these thorny questions and others during my session at THE Performance Improvement Conference, which takes place April 28 - May 2 in beautiful Montreal, Quebec. I’m delighted to have the opportunity once again to share my experiences and insight about Agile with ISPI colleagues.

While some are put off by the software-o-centric messaging of some agile gurus, what we find it that anyone who creates things as part of a team can tap into the benefits of agile. Many novice agiists get caught up in a cycle of putting tools and processes ahead of the mindset, losing sight of the fact that the tools and processes only work if they are support the application of agile values and principles. OK, so what?

In this session, I will propose three straightforward steps that beginning (and experienced but struggling) agile teams should consider. The terminology and concepts can be overwhelming, and we’ll attempt to simplify them together. After the presentation portion, I will lead everyone through an activity to translate my recommendation into a small number of realistic steps to take upon returning home from the conference. In the spirit of human performance technology, you will find this approach fully compatible with ISPI’s CPT Standards to which we are all subscribed. Along the way, we will reinforce the notion that we can all find meaning in work by striving for success with a shared purpose.

I look forward to seeing you in Montreal!

Bob Winter, CPT, is a senior principal consultant at CA Technologies, focusing on enterprise agile enablement and education. In addition to his experience as presenter at several ISPI and agile conferences, he is the author of Agile Performance Improvement: The New Synergy of Agile and Human Performance Technology, published in 2015. In recent years, Bob has focused on finding innovative ways to apply agile software development methods to non-software pursuits.