When Conflict Emerges, SCRUMstudy Helps You Manage

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.
-John Lydgate

In professional sports, whether you’re a benchwarmer or a superstar, when you become a “cancer” it is more likely than not that your days on that team (or in that sport) are numbered. “Cancer” is a label reserved for someone whose behavioral issues metastasize to other areas of the locker room, often triggering team-wide dissension. In these cases, teams routinely trade or release volatile players (as gifted as they may be) for restored harmony in the locker room.
The corporate world is not immune to the workplace “cancer” or occasional discord among colleagues. But organizations applying the Scrum framework encourage an open environment and dialogue. Conflicts among Scrum Team members are generally resolved independently, with little or no involvement from management or others outside of the Scrum Team. In other words, a “cancer” often goes into remission.
Conflict can be healthy when it promotes team discussions and encourages debates because this usually results in benefits for the project and respective team members. It is therefore important that the resolution of conflicts be encouraged, promoting an open environment where team members feel welcome to express their opinions and concerns with each other and about the project, and ultimately agree on what is to be delivered and how the work in each Sprint will be performed.
Conflict management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict evolve primarily due to schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality and costs. Usually there are four approaches to managing conflict in an organization applying Scrum processes: Win-Win, Lose-Win, Lose-Lose and Win-Lose. Let’s take a closer look at each with these discussions from A Guide to the Scrum Body of Knowledge (SBOK^™).
Win-Win: It’s usually best for team members to face problems directly with a cooperative attitude and an open dialogue to work through any disagreements to reach consensus. Organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them to reach Win-Win outcomes. SCRUMstudy endorses this approach as the optimal way to manage conflict, and suggests teams regularly resolve to achieve this outcome.
Lose-Win: Some team members may at times feel their contributions are not being recognized or valued by others or that they are not being treated equally. This may lead them to withdraw from contributing effectively to the project and agree to whatever they are being told to do, even if they are in disagreement. This situation may happen if there are members in the team (including managers) who use an authoritative or directive style of issuing orders or do not treat all team members equally. This approach is not a desired conflict management technique for Scrum projects, since active contribution of every member of the team is mandatory for successful completion of each Sprint. The Scrum Master should encourage the involvement of any team members who appear to be withdrawing from conflict situations.
Lose-Lose: In conflict situations, team members may attempt to bargain or search for solutions that bring only a partial degree or temporary measure of satisfaction to the parties in a dispute. This situation could happen in Scrum Teams where team members try to negotiate for suboptimal solutions to a problem. This approach typically involves some “give and take” to satisfy every team member—instead of trying to solve the actual problem. The Scrum Team should be careful to ensure that team members do not adopt a Lose-Lose mentality.
Win-Lose: At times, a Scrum Master or another influential team member may believe he is a de facto leader or manager and try to exert his viewpoint at the expense of the viewpoints of others. This approach is not recommended when working on Scrum projects because Scrum Teams are by nature self-organized and empowered, with no one person having true authority over another team member. Although the Scrum Team may include persons with different levels of experience and expertise, every member is treated equally and no person has the authority to be the primary decision maker.
With any team, conflict is bound to occur once in a while. You can’t please everyone every moment of your life. What is important is the manner in which conflict is managed. Of the four typical approaches to managing conflict, only one involves a win-win scenario. In order for such a scenario to be achieved, organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them with cooperative attitudes. Oftentimes, such treatment even leads to a cure for “cancers.”

Find more interesting articles about Scrum and Agile at http://www.scrumstudy.com/blog/when-conflict-emerges-scrumstudy-helps-you-manage/

Who Would You Like to Call “Master”?

Using the term “master” to describe someone’s boss today often conjures images of Igor addressing Dr. Frankenstein, Renfield heeding Count Dracula’s dark biddings or The Mountain doing Cersei’s dirty work. But in Scrum, the Master is one who serves you.
As a Scrum project begins, one of the important activities or processes is to identify the Scrum Master and the stakeholders using specific selection criteria. According to A Guide to the Scrum Body of Knowledge (SBOK™), “The Scrum Master is the ‘servant leader’ of the Scrum Team who moderates and facilitates team interactions as team coach and motivator.” In addition to the many soft-skill things they do such as mediating differences of opinion and temperament, each “Scrum Master is responsible for ensuring that the team has a productive work environment by guarding the team from external influences, removing any obstacles and enforcing Scrum principles, aspects and processes.” This last task of “enforcing Scrum principles, aspects and processes” is where the term “master” comes into play. The Scrum Master is a Master of Scrum—not of the people he or she works with. Those not wanting to become somebody’s Igor can breathe easier now.
What are the selection criteria for choosing a Scrum Master?
The preferred leadership style for Scrum projects is Servant Leadership, according to the SBOK™, and because the Scrum master must be a “servant leader,” it would be good to understand this term a bit. This term was first described by Robert K. Greenleaf in an essay titled The Servant as Leader. Greenleaf said that servant leadership “begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead.” Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

1. Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
2. Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
3. Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
4. Awareness—Awareness, and particularly self-awareness, is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power and values.
5. Persuasion—Servant leaders use persuasion rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion, as is typical in some authoritarian management styles, servant leaders practice persuasion.
6. Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing solely on the immediate short-term goals, is a unique skill of good servant leaders.
7. Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
8. Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
9. Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional and spiritual growth of others (that is, providing access to resources for personal and professional development, encouraging workers to participate in decision making).
10. Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have a strong mix of most, if not all, of these traits. Luckily, many of these traits tend to be developed together—the person with empathy naturally develops a commitment to the growth of others and this inevitably leads to a strong interest in building community.
The SBOK™ sums it up: “Servant leaders employ listening, empathy, commitment and insight while sharing power and authority with team members. Servant leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role.”
These traits also make an excellent description of a friend.  And that too is the embodiment of the Scrum Master role.
For interesting articles about Scrum and Agile, visit http://www.scrumstudy.com/blog/who-would-you-like-to-call-master/

SCRUMstudy Scrum video explains the Scrum Body of Knowledge

The Scrum Body of Knowledge (SBOK™) provides guidelines for the successful implementation of Scrum—the most popular Agile project management and product development methodology. It provides a comprehensive framework that includes the principles, aspects, and processes of Scrum.

Scrum, as defined in the SBOK™, is applicable to the following:

•             Portfolios, programs, and/or projects in any industry

•             Products, services, or any other results to be delivered to stakeholders

•             Projects of any size or complexity

The term “product” in this Body of Knowledge may refer to a product, service, or other deliverable. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

This first chapter describes the purpose and framework of the SBOK™ and provides an introduction to the key concepts of Scrum. It contains a summary of Scrum principles, Scrum aspects and Scrum processes. Chapter 2 expands on the six Scrum principles which are the foundation on which the Scrum framework is based. Chapters 3 through 7 elaborate on the five Scrum aspects that must be addressed throughout any project: organization, business justification, quality, change, and risk. Chapters 8 through 12 cover the 19 Scrum processes involved in carrying out a Scrum project. These processes are part of the 5 Scrum phases: Initiate; Plan and Estimate; Implement, Review and Retrospect; and Release. These phases describe in detail the associated inputs and outputs of each process, as well as the various tools that may be used in each. Some inputs, tools, and outputs are mandatory and are indicated as such; others are optional depending on the specific project, organizational requirements, and/or guidelines set forth by the organization’s Scrum Guidance Body (SGB). Finally, Appendix A contains an overview of The Agile Manifesto (Fowler and Highsmith, 2001) and a discussion of various Agile methods for those who want more information about Agile.

Note: For your reference please visit: http://www.scrumstudy.com/