Who makes the Best ScrumMaster?

As teams consider adopting Agile, one of the most important decisions they can make is who will be the ScrumMaster. Because the ScrumMaster is the promoter of Agile values and principals as well as the coach for ensuring the Scrum is being practiced effectively, it is critical that this role be filled with someone who is dedicated to implementing the Agile mindset.

A good ScrumMaster must have the ability to be an effective Servant-Leader. If is important to understand that a servant-leader takes a facilitative approach and does not apply command-and-control. Some key attributes include:

• Building a trusting environment where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of healing and problem solving.
• Facilitating getting the work done without coercion, assigning, or dictating the work.
• Ensuring the implementation of healthy Agile Scrum practices and values are followed on the project.
• Removing roadblocks or find the right level of personnel to remove the roadblock.

In the book “Practicing Servant-Leadership" by Larry Spears and Michele Lawrence, they share attributes for servant leadership. Some attributes include: listening, empathy, healing, awareness, persuasion, and foresight. Anyone who becomes a ScrumMaster should consider taking ScrumMaster training to help them understand their role and the activities they will facilitate. So the question arises, is there a traditional project role that plays the ScrumMaster the best?

Project Manager as ScrumMaster?
The seemingly obvious traditional role to play a ScrumMaster is the Project Manager. However, from my experience, there are pros with having a Project Manager become the ScrumMaster. On the positive side, the Project Manager has experience in being part of the team, so they may already have a trusting relationship with the team. Some Project Managers have built facilitative skills to lead work in a non-directive yet influential manner. And many already have the skills and the insight into an organization to appropriately remove roadblocks. On the negative side, Project Managers typically do not have technical experience into the product and cannot materially participate in technical discussions or provide meaningful technical insight. Also, some Project Managers had success utilizing command-and-control attributes and the more traditional Project Management practices which will not work well (and can be destructive) in an Agile environment. It can also be hard for some Project Managers to eliminate the traditional Project Management mindset of detailed project planning.

Functional Manager as ScrumMaster?
Quite possibly the most problematic role to play the ScrumMaster is someone who is a Functional Manager (aka, line manager, technical manager, etc.). Anyone playing a role where they have successfully directed people must make concerted efforts in removing their command-and-control behavior. On the positive side, they may have some technical experience into the product so can provide meaningful technical insight. They may already have the skills and the insight into appropriately navigating the organization and the ability to remove roadblocks. On the negative side, because they have been a manager of a team, so they may have issues with the team trusting them as a peer since they have been used to being judged by managers. A Functional Manager may have been successfully utilizing command-and-control attributes. However, this will not work well (and can be destructive) in an Agile environment. They must strive to remove their directive attributes and instead build facilitative skills. They must not assign work but instead enable and support team to become self-empowered. These are significant challenges.

Technical Lead as ScrumMaster?
Quite possibly one of the better traditional roles to play the ScrumMaster is someone who is a Technical Lead (QA Lead, Development Lead, etc.). By “lead”, I do not mean a manager or someone who has direct reports, but instead someone who is considered a lead by his peers. This person has a balance of leadership skills while wanting to get the work done. They typically have no interest in directing people. On the positive side, they have technical experience into the product and their specific field (development, QA, technical writing, etc.) so can appropriately aid the work (without direction or coercion and provide meaningful insight). They have experience at being part of the team, so may already have a trusting relationship with the rest of their peers. Because a lead does not have functional management responsibilities, they typically had to build their facilitative skills to lead work in a non-directive yet influential manner. On the negative side, they may not yet have the skills or the insight into an organization to appropriately remove external facing roadblocks.

Ultimately, the best answer to the question of what role best plays the ScrumMaster is not really a particular role, but instead which person best exemplifies the combination of the attributes of servant leadership, understands the Agile values and principles, embraces continuous learning, has a grasp of the technical aspects of the product under development, and can help remove roadblocks. In your organization, are there traditional roles that more often play the ScrumMaster role or best align with the servant leader attributes? If so, what is that role?  If not a role what attributes best exemplify a ScrumMaster in your organization?

----------------------------------------------------------------------------------------------------
PS - if you liked this article, consider reading "Who makes the Best Product Owner".

Knowing your Agile Personalities

When viewing the Agile world, it is beneficial to recognize the different types of folks on your team and in your organization. This can help you understand their perspective on Agile, if they are positive or negative on the topic, and what level of experience they have. Knowing these personality types can be very helpful if you are a professional looking to deploy Agile into an organization or product team. It is important to distinguish between personality types so you understand the people you are dealing with.

What I believe I may have recognized are seven personality types of people who are in the Agile space: the Innovator, Champion, Workhorse, Bandwagon, Cowboy, Deceiver, and Denier. Knowing these personality types can be very helpful if you are an Agile professional looking to deploy Agile into an organization or product team.  Here are details, highlighting the various Agile personality types including their experience levels in Agile, their positive or negative attitude toward Agile, the common roles that fit into a type, and their common attributes. While some folks fit squarely into one personality type, others may have attributes of two (or more) personality type.

Innovator

Agile Innovators make up a small population of folks in the Agile arena who are very experienced in this field and very positive about Agile. Agile Innovator is typically designated as an Agile industry leader and is motivated to improve and extend Agile methods, practices, and techniques. They can provide Agile leadership in an organization’s Agile adoption efforts. Many Agile Innovators have extensive Agile Coaching experience and have the ability to adapt Agile practices and methods to fit the context within an organization. They are motivated to educate others on Agile and understand how to get cultures (e.g., a cultural change agent) to accept Agile. Many Agile Innovators are consultants who move from company to company helping them adopt Agile. Those companies lucky enough to have hired an Agile Innovator as a full-time employee will have the benefit of having this expert to guide the organization through all aspects of an Agile adoption effort.

Champion

Agile Champions tend to know Agile well and are willing to advocate it in a very positive way across an organization. Some common roles in this space are Agile coaches, consultants, product managers, heads of engineering, development, and QA, and project managers. They make up a small, yet core, leadership in the Agile community and communicate the real meaning of what Agile is and what it means to have it applied. Folks in this role, play an important part of getting Agile adopted within an organization’s culture. They can help make it very clear in what conditions Agile will work. They can help communicate where there are challenges and help share new ideas in the Agile space. Agile Champions help generate Agile buy-in with Senior Management, many of which are part of bandwagon crowd (to be discussed momentarily), to initiate a new Agile culture (in pockets or throughout the company.

Work Horse

The Work Horse has learned about Agile by trying to implement it on their own or as part of an Agile team with some help from others. They are mostly positive about Agile but will be fairly honest on what works and what does not. The common role in this space are the members of an Agile team that have implemented Agile methods and practices. They bring a pragmatic approach to Agile, understanding the structure that Agile needs to thrive, by either being bitten once already or by understanding the environment needed for Agile. The work horse has worked in the trenches and really understands the challenges of implementing Agile because of their experience and they know that project success is tied to implementing Agile in an effective and pragmatic way. A lot can be learned from this group.

Bandwagon

The Bandwagon crowd sees benefits in jumping on the Agile bandwagon. Fads and trends rule the day in many organizations so if Agile is perceived to be "hot", then there will be folks who will jump on that bandwagon. Those in the bandwagon crowd tends to be inexperienced with Agile but are generally positive especially when they think it can help their own image or further their career. Some bandwagon folks are engineers who think they should align with the latest enterprise trend so they are perceived as team-players so appear positive since it places them in the right crowd. Some bandwagon folks are middle and senior management who are good at reading the winds of change within an organization and who believe they can get ahead by aligning with the hot new trend even though they may not have much interest in actually learning about that trend (in this case, Agile). They are very willing to "throw around" Agile terminology to give the appearance of knowing more about the field than they actually do.

Cowboy

The Cowboy sees Agile as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. Cowboys are the type of folks who are not necessarily negative about Agile because, in many cases, they know that they get away with pretending to be Agile since many folks, particularly the bandwagon crowd who are their up-line management, really have no idea what Agile is. It is the cowboy that has propagated the myth that Agile is an undisciplined approach for wild-west coders. Ultimately, these pretenders can give Agile a black eye in the organization since others will believe from the cowboy’s actions that Agile means no process. Agile methods instill much more rigor and discipline than most cowboys can tolerate and much more than many folks realize. You will find cowboys out there who know a bit about Agile, and just enough to know how to circumvent it.

Deceiver

The deceiver will provide surface agreement to using Agile but will silently attempt to ignore or even sabotage the project in order to put the blame on Agile. A deceiver is negative about Agile but is usually so because they have thrived using traditional or no method and see this as an impact to their working culture. Some deceivers may have been forced into a role on a team using Agile but do not want to lose any credibility by openly bad-mouthing the new direction. Some deceivers may have enjoyed their singular role within traditional methods and find the team approach within Agile not to their liking and will begin to subtly rebel in a passive-aggressive manner. Some will believe it will impact their career advancements or their compensation. Deceivers are the most dangerous because they may undermine and obstruct the potential success that Agile may bring to an organization and will attempt to hide any evidence of doing so, while a cowboy will try their best to simply avoid Agile.

Denier

The Denier will outright deny any benefit to Agile or their interest in moving to it. They are typically set against Agile from the beginning because they see that it will interfere with what they perceived to be their currently successful role within the company. Some deniers have thrived on playing a very specific role on a project and have been rewarded accordingly. Deniers typically do not have much Agile experience. It is actually better to have deniers than deceivers because with Agile deniers you know where they stand. The input from the deniers can help you understand their specific reasons for objecting to Agile (e.g., rewards, roles, loss of control, etc.). In some cases, by providing the deniers Agile knowledge, may lead them to be more positive impression about Agile, and in-turn some may become Agile work horses or champions. Also, by knowing who the Agile deniers are, they can be moved to other projects that are not going to Agile and where they may can continue to provide value to the company.


Consider reading more on this topic in full article: Agile Personality Types