ScrumMaster Beyond the Team Debrief


In a recent presentation to the Red Hat Agile Community, I prepared a talk on the ScrumMaster role outside of the team. It took several weeks to put this together; I really wanted this to make an impact and motivate the group. This topic contained some very important information, but the delivery could easily sway the intended audience to either listen or ‘shut down’. The primary objective focused on the role a ScrumMaster plays after his/her team becomes high performing. I was using my own professional anecdotes and Essential Scrum as the basis for my case. Specifically,  in Essential Scrum  Kenneth Rubin states, “Usually as the Scrum team’s need for a ScrumMaster decreases, the need for the ScrumMaster to focus on broader organizational impediments and to be a change agent throughout the organization value chain increases” (192). However, the secondary intent aimed at motivating ScrumMasters that have grown complacent in their role. The Red Hat Agile community is in its early stages, and it needs the unified effort of its ScrumMasters and practitioners to truly make a difference within the organization. After deliberating the delivery of the speech, I opted to take a more informative approach instead of my usual ‘fire and brimstone’. This approach would appeal to most in the Red Hat Community, avoid alienating anyone who might interpret the speech incorrectly, and inspire some to take the next steps in their agile careers. The following is the written version of the speech.


ScrumMaster Beyond the Team

Whether we like it or not, the ScrumMaster’s job does not end with the team. When we are certified, we are constantly bombarded about our responsibilities to the team. Our duty is to serve team first. We do Agile in Practicethis daily by coaching our teammates, seeking ways to continuously improve, protecting the team against blockers, and serving as ambassadors between the team and its customers.  Our goal is simple: Get our team to achieve high performance. Some ScrumMasters choose to stop here; serving as a ScrumMaster on a high performing team adds the temptation to grow complacent. I contend that there is much more value a ScrumMaster can provide. Though we are always dedicated to our team, we have a deeper calling to the organization and the overall agile community.


Impact on the Organization

The software development industry is riddled with organizations that practice ‘dysfunctional agile’. Yes, Scrum, Lean, Kanban, and many other frameworks are proclaimed in IT hallways, but chances are that upper management has no idea what it means. In other organizations, there exists direct or indirect resistance to any kind of transformation. In these scenarios I ask, ‘Where are the ScrumMasters!?’ Though the organization may not be practicing scrum, I consider change agents and members of the adoption team are ScrumMasters/Coaches. These organizations need involvement from their agile practitioners to properly align the organization on why they have chosen a collaborative strategy instead of how to collaborate. Essential Scrum details the roles good ScrumMasters can play in these scenarios:


A good ScrumMaster must help change minds as well. Scrum can be very disruptive to the status quo; the change that is required to be successful with Scrum can be difficult. The ScrumMaster helps others understand the need for change, the impacts of Scrum outside the Scrum team, and the broad-reaching benefits Scrum can help achieve. The ScrumMaster also ensures that effective change is occurring at all levels of the organization, enabling not only short-term success but, more importantly, the long-term benefits from using Scrum. (187)


It takes courage to accept change, but it takes almost an inhuman amount to lead it. During adoption and implementation, opportunities will arise for ScrumMasters to influence organizational change. Exercising tact while addressing areas of improvement is critical; you don’t want those listening to shut down before you even get a chance to propose a solution. We are the messengers of the good, bad, and the ugly; in order for our organizations to to trust us, we must be able to deliver it all.


While leading an agile adoption at one of my previous employers, our adoption team spent many days working with executives and management who were curious and skeptical. We worked to answer all their questions and concerns, and we took the time to research the answers when we could not. I’ll never forget how nervous the adoption team felt when we pitched adopting scrum to the IT executive team; you could’ve cut the tension with a knife. However, our ability to convey why we felt the change was necessary won them over, and we never looked back. Many of those on the adoption team eventually became ScrumMasters and Product Owners. We accepted the duties for our teams, but we knew we also served an organization about to go on a ‘rollercoaster’ journey.


The Agile Community

What good is knowledge if we don’t share it? Former Google CIO and VP of Engineering, Douglas Merrill, once said:

“Knowledge was power, back when knowledge wasn’t easily available or disseminated. If you lived in the 1600s and wanted to be a stonemason, you’d start off as a master’s apprentice. Instead of paying you, he’d teach you his trade. He could do this because he had the knowledge you couldn’t get elsewhere. He had power. You? Not so much.”

I’d like to encourage all agile professionals to communicate and collaborate by any means possible. This is not a community where knowledge hoarding is rewarded. Start a blog, write articles for printed and online magazine’s, attend local or national conferences, get your certifications, etc. The idea or tactic you used to help improve your team may help out a fellow professional. Just as we push our teams to continuously improve, we must do the same same with our own careers.


Don’t Get Comfortable

When making a very big professional decision my father gave me some excellent advice. He said, ‘A lot of times when someone feels comfortable they get lazy. When people get lazy, they can’t grow. If you’re comfortable, son, you will not push your limits. Sometimes we need to make ourselves uncomfortable in order grow.’ At the time his advice sounded so broad, but the more I reflected on it, the more I understood my direction. I made the decision that wasn’t the easiest, would surely push my limitations, and would inevitably lead to growth. It was also extremely risky, but I couldn’t let fear dominate my decision. Though frightening at first, this decision eventually led to starting this blog, writing articles, making presentations, putting user groups together, and getting involved with the agile community. It certainly wasn’t something I felt very comfortable in, but it was a series of deliberate decisions that offered growth opportunities.


The Journey

A ScrumMaster begins his/her journey as an individual that makes a commitment to to his/herself. We then join our teams and start marching towards the goal of high performance. If our teams reach Screen Shot 2015-03-27 at 1.34.15 PMhigh performance, opportunities will open to make impacts in the organization and beyond. As professionals, our organizations and the agile community cannot afford to have us sit on our certifications and knowledge. Complacency is not in the ScrumMaster dictionary… we threw it out when we made our decision.



  • Rubin, Kenneth. “ScrumMaster.” Essential Scrum. Pearson Education, 2013. 191. Print.




Story Writing Tune Up

Earlier this month, I was asked to make a presentation on story writing. The material needed to cater to an experienced team; I aimed to provide advanced techniques while revisiting some of the basics of story writing. The presentation was a hit, and the team loved the content. I put together my first narrated power point show for the world to view. Enjoy! Many thanks to Arjay Hinek and Catherine Louis; much of their work served as an inspiration in putting this together.


User Stories Tune Up Presentation
User Stories Tune Up Presentation

New Publication on Cutter IT Journal

In January, I was approached by the Cutter IT Journal about writing a follow-up to my October 2014 print article, Agile Team 0. Seeing this as an excellent opportunity to take a retrospective approach on the team, I put something together. You’ll need a subscription to Cutter; fortunately, I can forward the article via email if interested. You can also sign up for a free trial; they have some very good content.


Picture for Your Thoughts

Everyday, my father sends me a ‘Daily Starter’. Many of them are filled with inspirational quotes and words of wisdom. However, this simple picture hit home one morning. I think Steinbeck said it best in Of Mice and Men: “The best laid plans of mice and men often go astray”.


Traditional sequential delivery models lay out the entire plan at the beginning of a project- illustrated by the top photo. However, the bottom photo clearly illustrates the world of software development; it actually looks like a pleasant and scenic route compared to what software professionals really endure. If adopting an iterative approach can be so obviously illustrated, why aren’t most organizations so reluctant to change?


Scrum Master Misunderstood

The majority of the texts on Scrum describe Scrum Masters as a shepherd or protector of the team. You’ll often hear the ‘servant leader’ buzz term associated with Scrum Master. Of the three major roles in Scrum, the Scrum Master is often the most misinterpreted. I believe this stems from a failure to understand servant leadership combined with an organization’s knack for placing the wrong personnel in that role.


Servant Leadership

The term servant leader contains a very profound history. The term leaves the lips of many in organizations, but they know little of its true nature. To understand the term, lets examine its origins. The idea of the servant leader reaches as far back as fifth-century BC; during this period Lao-Tzu, the Father of Taoism, planted the seeds of the modern day definition of servant leader:

The highest type of ruler is one of whose existence the people are barely aware… The Sage is self-effacing and scanty of words. When his task is accomplished and things have been completed, all the people say, ‘We ourselves have achieved it!’

In 1970, Robert Greenleaf brought this ideology into the modern world in his paper, The Servant as a Leader. In it he states:

The servant leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead… (vs. one who is leader first…) … The best test, and difficult to administer, is: Do those who served grow as persons … (and become) more likely themselves to become servants?

Organizations have not wrapped their heads around this concept. The possibility of losing control and power strikes fear into the hearts of those in leadership today. In the software development industry the command and control model is slowly crumbling, as evidenced by the increase of agile transformations across the globe. Rather than swing from one end of the spectrum to the opposite, I propose organizations find some ground near the middle.

In his book, Turn the Ship Around: A True Story of Turning Followers into Leaders, David Marquet describes an unorthodox approach he took with an underperforming crew; his model was contrary to the Navy’s traditional command and control, but he gained the trust of his superiors to try it on his crew. David implemented a system of ‘Intent Based Leadership’ that aimed at creating leaders throughout his crew. His implementation was a success, and it created a sense of ownership, accountability, and pride. In this model, a captain still exists; instead of focusing on giving orders on how to execute tasks or solve problems, the captain allows the crew to pull their training together and solve the problem as a team. The captain is there to facilitate and guide the crew/team to the solution, not provide it directly. The ultimate goal is to grow your team, so its members can excel both personally and professionally- self organization.


Who Gets to be a Scrum Master?

Welcome to the pitfall question facing most organizations today. In the face of transforming roles and job titles, organizations resort to filling Scrum Masters with traditional jobs- project managers, tech leads, architects, supervisors, etc. Based on what we discussed above, placing someone in a Scrum Master role because they can drive teams on a schedule, create beautiful technical designs, or write outstanding performance evaluations is far from the correct criteria. Recall, Scrum Masters have no true authority on a team. Electing an individual that shows strong authoritative characteristics may prove disastrous for the team and individual. Some of the desired characteristics of a Scrum Master include (add these to the lists you’ll find on the internet):

  • Introduces opportunities of growth for the team
  • Mentors the team in its practice of Scrum
  • Leads the team to solve challenges on their own
  • Rather than rely on metrics, intuitively understands the needs of the team and make adjustments where necessary

None of the above contain directive attributes- very different from command and control leadership. Most other authorities on Scrum will provide the same attributes. A good Scrum Master successfully battles the temptation to take the wheel and change course; instead, he/she is masterful (pun intended) at guiding the team to the conclusion that a change of course might be necessary. In summary, the Scrum Master embodies the visions of Lao-Tzu, Greenleaf, and Marquet. In order for a team to grow, they must take the wheel and lead.


Closing Thoughts

It will take some time before the Scrum Master role is understood by the majority. Servant leadership is a concept that is difficult to grasp in a society that glorifies the command and control model. Organizations that practice or intend to practice Scrum must carefully evaluate the criteria for Scrum Masters before blindly appointing candidates. The old leadership mold doesn’t fit in the software development industry. It may be a hard pill to swallow, but the agile frameworks, such as Scrum, cannot function healthily without it.




Marquet, L. David. Turn the Ship Around!: A True Story of Turning Followers into Leaders. New York: Portfolio, 2012. Print.

Greenleaf, Robert K. The Servant as Leader. Indianapolis, IN: Robert K. Greenleaf Center, 1991. Print.

Heskett, James. “Why Isn’t Servant Leadership More Prevalent?” Forbes. Forbes Magazine, 1 May 2013. Web. 22 Dec. 2014.