Kamlesh Ravlani, Author at Scrum Certification Training and Agile Coaching
The Scrum Master as a Coach – Kamlesh Ravlani

The Scrum Master as a Coach – Kamlesh Ravlani

by | Apr 17, 2019 | Agile Coaching, Scrum Master

Coaching is one of the essential skills required for a Scrum Master to be effective. Coaching along with Facilitation and Teaching skills enable the Scrum Master to be successful at their role.

The Scrum Master coaches the Development Team, the Product Owner, and the Organization. Coaching empowers and brings out the best in them.

A coach helps in unleashing a person’s or a team’s latent potential. This helps to maximize performance with the same amount of effort.

It's about empowering the people to learn to solve their own problems rather than teaching them or solving problems for them.

The Scrum Master as a coach helps the Scrum Team as well as the organization, adopt Scrum and enhance team and enterprise agility.

Jump to Topics Below:

What is Coaching | How Coaching Works | 7 Must have Skills for a Scrum Master to be a Coach | Why does a Scrum Master act as a Coach? | PLEASE - Scrum Master's Coaching Model | SCARF - Neuroscience based Coaching Model | Who does the Scrum Master Coach | Role and Responsibilities of a Scrum Master as a Coach | What type of a Coach is the Scrum Master | Difference between a Scrum Master and a Scrum Coach | Duration to become a Great Coach 

What is Coaching?

Coaching is a collaborative intervention used by a coach to help their coachee(s) to improve and move forward towards a better future (improbed behavior, achieve goals, effectively handle certain situation, etc). Unlike mentoring, counseling and educating, coaching doesn't need the coach to have all the answers or to be a subject matter expert. The coach creates a structure and a safe environment where the coachee can be open and vulnerable to experiment and eventually grow.

How Coaching Works?

While coaching, the Coach helps the coachee to clarify the challenge they want to address. Staying neutral, the coach holds the structure, a safe place within which the coachee can go through the transformation.

Coachee addresses the challenge at hand. In the process, coachee develops capability and is on the way to attain a better future.

What does a Coach do?

The Scrum Master as a coach:

> asks powerful questions: empowers the scrum team to find their own answers rather than giving them the answers. 
> actively listens with an open mind: allows the coachees. to reflect and bring clarity to their thoughts.
> reflects back: enables coachees to become aware of their own thinking, behavior and actions.
> challenges thinking: leads the coachee out of her comfort zone, motivates to break limiting mental patterns.
> helps the coachee look at their blind spots: saves them from catastrophic failures and making costly mistakes.
> helps the Scrum Team and the PO develop focus and avoid distractions.
> helps the Scrum Team discover their values and purpose.
> helps establish clarity of thoughts / objectives: reduced ambiguity helps the team with rapid decision making.
> Enables structure and culture that promotes taking actions, and
> holds coachee accountable to act towards their desired future.
> Develops her coachees to find and activate their inner coach to sustain the coaching momentum after the formal coaching is over.
> Maintains neutral stance while maintaining the structure for the coachees to lead the action.
A great Scrum Master as a Coach:
> Believes in the capabilities of her Scrum Team
> Is flexible and adaptable
> Is kind and compassionate towards members undergoing transformation
> Is Empathetic
> Is Open and Respectful
> Is Neutral yet Assertive when needed
> Enables personal, phychological safety for everyone
> Is ok being wrong and allows team members to fail
> Builds Trust and respects confidentiality of personal matters
> Models the Agile Mindset and behaviors that she advocates to others
> Is able to observe blind spots and holds a mirror for the coachee to see the same.

7 Must-have Skills for a Scrum Master to be a Coach

Below are the 7 skills that make a Scrum Master an outstanding Scrum coach:

Establishing a Trust based Relation: A pre-requisite for an effective coaching is a relationship based on trust and respect. A trust-based relation allows the coachee to be vulnerable, feel safe to discover their potential and transform to get better. In the presence of trust, team members can open up and share their mistakes. Failures become learning opportunities, and it is easy to seek help.

When people have built relationships, getting things done becomes smooth. The focus can stay on making positive progress. Collaboration becomes a natural way of working when team members enjoy working with peers.

Scrum Master achieves this is by creating an environment of radical transparency. Transparency of information improves trust.

Scrum Master ensures the Scrum values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team. Scrum values foster trust among all.

The Scrum Master acts as a bridge to establish trust based relationship.

Generative Listening: The success of all coaching conversations depends on the ability of the coach to listen deeply.

It requires practice to listen to what people say. But to be able to listen to what is, it takes a whole lot of letting go. Such as shedding the internal biases, personal agenda, the need for winning, and silencing the inner self. This level of listening requires being in the moment.

The coach with an open mind listens to what is being said and strives to understand the deeper meaning and emotions behind those words. By being open the coach allows for the future possibilities to emerge.

Generative listening is listening with a purpose to serve, it has empathy, openness and allows possibilities to emerge.

Let's think for a moment. You are the Scrum Master coaching a Manager. You carry an internal bias about this person's attitude, their management style, and have a preplanned agenda you would like to push.

Will you be able to effectively coach this manager?

Irrespective of this manager's willingness to learn, the coaching intervention will not help the manager, if the coach isn't listening.

The Scrum Master allows space for the coachee to talk and discover her capabilities. To come up with answers and solve their own problems. This allows the coachee to sustain their growth and accomplish highest future possibility.

Powerful Questioning: The Scrum Master uses powerful questions to fuel coaching conversations. The Scrum Master learns and practices this art of asking questions.

What makes a powerful question?

A powerful question is unbiased, clarifying, open-ended, inviting, challenging, solution focused and empowering.

By moving away from telling, answering and solving, the coach takes a stance of asking powerful questions.

Find dozens of powerful coaching questions I've posted on my Linkedin and Twitter profiles.

Leading by Example: To be able to earn trust and influence others, the Scrum Master must exhibit behaviors that she so desires from her coachees. A good coach has a learning attitude, welcomes feedback, continuously works on improving herself, is flexible and is comfortable to experiment and fail.

If the Scrum Master isn't a servant leader herself, will she be able to effectively coach the organizational leaders to become servant leaders?

The Scrum Master by practicing agile mindset instead of simply preaching it inspires others to continuously improve their agility.

Focusing on the Present: What helps people move forward and make progress is living and acting in the present.

It’s not uncommon for many people to carry the baggage of negative experiences of past with them. Such baggage not only drags them down from moving forward but also usually prevents them from trying new things. On the other hand, you’ll also find people living in the fantasy world of future, having grand plans which try to perfectly lay out everything. Most assume that everything will be awesome one day – by itself.

A good coach lives in the present and helps the coachee make the best of the opportunity at hand, accept the present and adapt to the situation at hand by taking action in the now.

Acknowledging the coachee as Whole and Resourceful: This comes from Co-Active Coaching approach that emphasizes that – People are inherently whole and resourceful. They don’t to be fixed. If the Scrum Master accepts this she will be able to allow the coachee the freedom and empowerment to find their own solutions. She challenges constructively, provides structure, constructive feedback and avoids criticism.

Being a Servant-leader: The Scrum Master as a Servant Leader operates from the stance of serving others. Serving the Scrum Team is an essential responsibility of a Scrum Master.

The Scrum Master is a Servant-Leader for the Scrum Team - Scrum Guide

The Scrum Master models servant-leadership behavior that inspires others. She focuses on serving team's agenda and not own agenda. Her objective is to be able to serve her people, empower them and help them build the capability to deliver the best they possibly can.

Why does a Scrum Master act as a Coach?

The Scrum Master is responsible to help the team grow to be a cross-functional and self-organizing team and derive maximum benefits of adopting Scrum. Moving from traditional functional silos and top-down driven teams to cross-functional and self-organizing teams requires a major shift in the behaviors of people, in the organizational structure as well as culture.

Coaching is the best intervention to accomplish deeper and sustainable change in the way people think and behave.

The Scrum Master brings a thorough understanding and practical application of the Scrum values, the Scrum framework and its rules. This knowledge and experience informs the Scrum Master to identify the most appropriate intervention for the context. Coaching being one of that intervention in the Scrum Master's toolbox.

While the Product Owner is responsible for improving ROI through Product direction, the Development Team is responsible for translating the Product Owner's vision into working product and delivering high-quality product increment, the Scrum Master is responsible for building the capability within the Scrum Team to maximize the value it can deliver.

Since the Scrum Master is not responsible for product direction, delivering the product and people management, she can observe the action on the ground as well as step back to view it from a 30,000 feet view. Allowing her an opportunity to bring back observations and insights which may be blind spots for the team.

If the Scrum Master observes the Scrum Team derailing from any of its own goals, she can help them get focused and quickly help them channelize their effort to reorient the Scrum Team toward meeting the bigger organizational goal.

PLEASE - Scrum Master's Coaching Model

From my experience coaching Scrum Teams, I've distilled my coaching approach to a simple 6 step model. I've termed this Scrum Master's Coaching Model as PLEASE model. The PLEASE model is simple and helps me prepare everytime I'm starting to coach a new Scrum Team. It also helps me stay oriented to serve the team. The PLEASE model is:

Prepare for the coaching conversation - Scrum Master should prepare before for the coaching conversation. Be open, shed any bias towards the coachee, understand the context within which the coachee operates. Come to the coaching conversation with full enthusiasm and positivity.

Learn about the customer’s need - Ask the Dev Team, the PO, and the stakeholders and learn what is their desired outcome. What positive future they intend to create. Most coaches miss this aspect and jump straight into solving problems they see on the surface. Avoid the trap of being and showing yourself as busy.

Not all running is reaching.

Understand the desired destination first, before you start running towards it.

Establish the environment of safety and openness - A fundamental pre-requisite of a good coaching conversation is an environment of mutual trust, safety, openness, and privacy. It's an unspoken contract between the coachee and the coach. It is the responsibility of the coach to establish such environment before the coaching session begins. Only when the coachee feels safe enough they will open up and take the position of vulnerability which paves way for their further growth.

Accept expected behavior - A major portion of Agile Coaching involves helping people bring a change in their behavior. Before starting the behavior change, understand that most people’s behavior is a reflection of what is expected of them in the organizational environment. People mostly Accept the current behavior of the team members, the PO and people within the organization —  Before starting the behavior change, you must first, without judgment, accept that the current behavior of team members and managers is mostly a reflection of the expected behavior in the current organizational environment. Simply stating a particular behavior is not Agile will not help your coachees. Help them see their behavior from a different angle and let them decide what they would like to do the same.

Specify behavior change - Accepting the current and expected behavior does not mean, your coachees should continue with the same behavior. The Scrum Master helps coachees understand the need for the behavior change as aligned with their own transformation goals.

I was the new Scrum Master for Pluto team. The developers on this team would not mind if any stakeholder would come up to one of the team members, pull them out and assign them random tasks. They would miss a story or end up working extra hours to finish the sprint plan. Surprisingly they will not bring up this at the Sprint Retrospectives either. At the end of one retrospective, one team member asked for my input when they missed delivering two stories. I asked if this was of interest to any other team member as well - most showed interest. We agreed to have this discussion with the team the next day.

I invited them to take a couple of minutes and self-assess the team on how they were doing on the Scrum Values.

They were quick to come back with observations stating "We need to show Courage and stay Focused on delivering the Sprint Goal." I supported their observation while emphasizing that it was essential that every team member ensured that they followed all the Scrum values well.

Embed new behavior - It helps the team, the PO, and other people within the organization to embed new behavior in their daily way of working. The Scrum Master may facilitate the same. Hold the people accountable to continue making efforts. Challenge them if they slow down or feel exhausted as the new behaviors may require additional cognitive processing and discipline. The team may need a couple of reminders and bit of experiences that embed this new behavior. Like any change, make this change small and incrementally build up.

I like the PLEASE coaching model for its simplicity and effectiveness. What's important is that it works for me.

I've refined it over the years to be simple yet powerful.

If you are a Scrum Master and would like to use the PLEASE model in your coaching, give it a try. Feel free to reach me with your experiences applying it.

There are other coaching models that the I've applied based on the need and context.

The coaching approaches I like the most are:

- Co-Active Coaching Model by Henry and Karen Kimsy-House

- Emotional Intelligence Based Coaching by Daniel Goleman, Richard Boyatzis, and Dan Siegel

- Theory U and Presencing by Otto Scharmer and Peter Senge

Scrum Master Coaching Model - PLEASE

SCARF - Neuroscience based Coaching Model

SCARF stands for: Status, Certainty, Autonomy, Relatedness, and Fairness. In the video below, David Rock the creator of SCARF model, explains the neuroscience behind it.

SCARF model involves five domains of human social interaction. It originated based on key discoveries in the field of Neuroscience about the social interaction among people.

Three central ideas of the SCARF model are:

1. The human brain treats social threats and rewards with the same intensity as physical threats and rewards (Lieberman, & Eisenberger, 2009).

2. The capacity to make decisions, solve problems and collaborate with others generally increases under a reward response and decreases by a threat response.  (Elliot, 2008).

3. The threat response is more intense and more common. It often needs to be carefully monitored + minimized in social interactions (Baumeister et al, 2001).

The role and responsibilities of Scrum Master as a Coach

What are the responsibilities of a Scrum Master as a Coach? The Scrum Master supports and enables the dev team, the PO, and the organization through coaching to deliver the highest value to the customers, improve the ROI and develop adaptability within the organization.

Let's explore how does the Scrum Master coach each of the roles?

Scrum Master as a Coach to the Development Team:

The Scrum Master may spend significant time and effort coaching the development team. More so where serving a team new to Scrum.

The Scrum Master coaches the development team to accomplish these four outcomes.

Self-Organization:

The Scrum Master coaches the development team and the organization to transition from top-down and externally managed to a self-organizing team. The Scrum Master helps develop this vision of Self-Organization within the team. The SM creates an environment within which the team members can try smaller experiments to move towards self-organization.

During this transition, the Scrum Master must protect the development team's boundaries. Protecting team's boundaries offers:

> Space and time for the development team members to step forward. To exercise the empowerment offered to them and assume the responsibility. Most Development Teams usually take time to migrate from one person having all the answers to let's find out the answer as a team.

> To neutralize the external influences from the top-down organization.

> To create a perimeter of the decisions that the team members can take themselves without having to go to others within the organization.

The Scrum Master makes the team's efforts and progress visible towards becoming a self-organizing team.

Cross-Functionality:

The Scrum Master coaches the Development Team members to acquire broader, cross-functional skills. The development team members move from being single function experts to become cross-functionally skilled members. Their skill evolution may look like a T-Shape, Pi Shape and eventually Broken-Comb-shape.

A product group I was coaching at a major global bank comprised of 3 teams. Most of the team members were single function focused. Some called themselves Java developers, some called themselves FrontEnd Developers having skills with JavaScript, CSS, HTML 5, others were Business Analysts, UX Designers, and Quality Assurance Engineers to name a few.

At an appropriate opportunity, I asked the team - How is it (being single function focused) working for you?

Single function expertise sounded efficient on the surface, however, it was causing local-optimization at the cost of reduced system-optimization.

When asked, the Team members were quick to raise their observations and concerns. With single function focus, the team was producing a lot of waste in terms of hand-offs and waiting. Lack of collaboration was the norm. Some team members were always overloaded and others had intermittent work.

With some further poking, asking clarifying questions, and allowing them to create a vision of betterment, the team members came together to script a better future for themselves in terms of cross-functionality.

The first milestone they set for themselves was to broaden their focus and to be able to work on at least two functions in next 4 months.

Team members self-selected the area which they wanted to learn. Some started collaborating with BAs to learn more about the domain and customer collaboration, others started working with QAs to get better at verification / validation and some leveled up to create wireframes and learn the UX design aspects.

I facilitated the environment, movement of desks, additional white-boards, and flip charts etc to enable opportunities for collaboration, pair-programming and sharing knowledge.

Soon, the team members started doing one-hour knowledge sharing sessions every Thursday afternoon. Team's slack now got an additional Knowledge Sharing channel where insightful articles, code snippets, and Tutorial videos were being shared.

Foresee and Remove Impediments:

If the job of a good coach is to work themselves out of the job, then the Scrum Master must coach the Dev team to foresee and remove the impediments themselves. The Scrum Master coaches the team to practice it. Maybe mentor a bit in the beginning. This requires a bit of practice on part of the development team. To be able to shift focus from day-to-day tasks to step back and look at the action from ~10,000 feet and sense for patterns.

A good Scrum Master may challenge the team members to figure their own version of approach to finding and fixing the impediments.

Improve Collaboration:

Being Agile is a team sport. It requires intense collaboration among the team members. To rapidly deliver value in small increments, seek customer feedback and adapt to customer needs.

The coach helps the team to embed collaboration in their ways of working, making decisions, planning and execution.

Scrum Master as a Coach to the Product Owner:

The Scrum Master coaches the Product Owner in following areas:

> To improve Product Backlog Management efficacy.

> To understand the empirical way of Product Planning.

> To order the PB to maximize business value.

> To understand and practice agility: The Scrum Master coaches the Product Owner to internalize the concept of agility and what being adaptable means.

The Scrum Master holds the Product Owner accountable to identify market changes and adjusting direction to minimize risk and maximize ROI.

One of the common dysfunctions I’ve witnessed with the Product Owners is the false certainty they bring to the development teams in the form of requirements. The underlying assumption is that if my team builds it, we launch it, the customer will pay for it.

In one of my assignments, I asked the Product Owner:

Jenny, what makes you say that the customer will pay for this feature?

The coach may challenge the PO to distinguish between the user asked requirements and the hypothesis.

The Scrum Master coaches the Product Owner to internalize the concept of agility and what being adaptable means. The Scrum Master holds the Product Owner accountable to identify market changes and adjusting direction to minimize risk and maximize ROI.
To experiment small and adapt.

Coach the Organization:

The Scrum Master coaches the people in the organization to develop a learning organization that is flexible and adaptable to market changes.

Some of the major challenges and opportunities while coaching the organization are:

> Developing Agile Mindset throughout the organization.

> Bringing the necessary changes in all the functions (HR, Marketing, Finance, etc.) of the organization to improve the flow of value.

> Removing the functional silos to improve cross-functionality.

> Building bridges of collaboration within the organization that make the hierarchy irrelevant.

> Pave way for the organizational culture to be conducive to experimentation and adaptation.

> Develop a learning organization.

> Help the leaders identify System Optimization Goal for the organization.

> Create a culture of investigating the root-causes and immediately acting to address them.

What type of Coach is the Scrum Master?

Back in days, when I was learning Coaching, I observed there are various types of coaches and coaching interventions. There are few dozen varieties of coaching and coaches. Some of the most commonly known coaches are Life Coach, Sports Coach, Business Coach, Leadership Coach, Behavior Coach, Strengths Coach, Career Coach, Relationship Coach, etc. I kept thinking and asking, which type of a coach is the Scrum Master? It turned out there was not a single type.

As a Scrum Master, you'll find that the good Scrum Master's coaching styles, approaches, and techniques are similar to and a combination of these coaches.

Team Coach:

Most common application for the Scrum Master's coaching is to coach the Development Team. Usually, multiple team members are part of the intervention. This is pretty different from one-one coaching. The focus of team coaching could be for example to build a high-performance team. The Scrum Master acting as a team coach may help the team accomplish this by fostering collaboration, creating shared ownership and creating accountability within the team.

Individual Coach:

The Scrum Master has to be comfortable coaching the individuals in 1-1 sessions. Particularly the Product Owner, and managers that have a high influence on the team. Also, any difficult to work with team member and team member who may be finding it challenging to keep up with the team's expectations may benefit from 1-1 coaching intervention with the coach.

My reference for this type of coaching is the Co-Active Coaching model by Henry and Karen Kimsey-House. I've been fortunate to take Karen's workshop on Co-Active coaching in Boston.

Behavioral Coach:

I found this out very early in my Scrum Master career that without invoking positive behavioral changes within the people, my efforts to serve the team in creating a high performing team will yield only limited and short-lived results. The behavioral coaching may not necessarily be called so and may be embedded within the Scrum Master's regular coaching interventions.

From my experience coaching Scrum Teams and Agile Leaders, some of the behavioral changes desired by coachees have been: Moving from traditional control style to self-organization, from plan-it-all to being comfortable with iterative planning, from can't-fail to experimentation mindset, from someone will assign me the work to what can I do to help the team accomplish its goals behaviors.

My role model to learn behavioral coaching has been Marshall Goldsmith. I've read 4 of his book and gifted those to about a dozen of my colleagues and friends.

Leadership Coach:

The Scrum Master as a coach to the managers and leaders is a key to bringing deeper changes within the organization and getting leadership support. If you as a Scrum Master have ignored this aspect, time to start thinking about it. Effective coaching for the leaders will significantly benefit your team see reduced resistance from the organization and increased support from immediate leaders.

The Scrum Master may help the leaders adapt Agile mindset, remove confusion about the changes, bring clarity to their role during and after the change, and help the leaders with improving their leadership agility.

I highly recommend Leadership Agility by Bill Joiner to improve your Leadership Agility as well as help your leaders.

Sports Coach:

Like the Sports Coach, the Scrum Master aka the Scrum Coach's coaching is informed by her experience and expertize of Scrum Framework. At times the Scrum Coach may need to step in and share with the team about what is Scrum and what it is not. What practice may be added to the Scrum Framework and which practice may add waste to the process. Here the Scrum Master may take the mentor role and help the unaware people to become educated on a specific practice or rule of Scrum.

Refer writing about the most successful Sports coaches like - John Wooden, Vince Lombardi and Phil Jackson.

Being effective at coaching requires the Scrum Master to be able to find the most appropriate technique and style that fits the context and the Scrum Team's needs. Scrum Master must develop a wide array of coaching skills to be able to pull one out on the fly.

Difference between Scrum Master, Scrum Coach, and Agile Coach

A plethora of dozen a dime Agile Coach certifications are now available by various organizations today. To improve the selling ability of these certifications, each one has launched their versions of the terminology referring to the Coaching aspect associated with Scrum Framework and Being Agile.

In its most fundamental and simple state the Scrum Master should be empowered enough to be able to coach (as discussed above) the development team, the Product Owner as well as the Organization - that the leaders within the organization, their decisions, the organizational structure and associated policies and the organizational cultural aspect.

However, in traditional hierarchical organizations, it is highly uncommon for a Scrum Master to be able to get regular time and visibility with top decision-makers of the organization.

Without much empowerment, these Scrum Masters can only fantasize about coaching their leaders. This dysfunction is much bigger and a tough one for these Scrum Masters to be able to address.

Also wouldn't it be too low for a Vice President to get coached on Enterprise Agility by a Scrum Master who may be 8 levels below them in the organization chart?

Such situation has given a rise to different levels of coaches in such organizations.

Most commonly used terms for the experienced Scrum Master acting as a Coach in the Scrum and Agile industry today is Scrum Coach and Agile Coach. Newer variants you may also hear these days are Team Agile Coach and Enterprise Agile Coach, etc.

Accept it or not, if someone keeps calling them as a Scrum Master for 10 years, industry today will not value or respect them as much as they would to someone who calls them Enterprise Agile Coach having only 2-years experience in the industry.

No surprise more and more people attend 2-day training and start calling themselves Enterprise Agile Coach. Volla!! You are immediately in demand now 🙂

In an efficient organization, there would be no need for 3-5 levels of Scrum Masters to Enterprise Agile Coaches. The Scrum Master should be empowered enough to work with the organization, help bring up organization level impediments, work with leaders, and contribute to policy changes required etc.

Rants aside, if you are hiring Agile Coach whether at a team level or at an Enterprise Level - first you want to see if the person brings hands-on experience working as a Scrum Master. I prefer 5 years minimum Scrum Master experience before a person can really get the handle of the vast field and impact an Agile Coach can create on the teams and enterprises as Systems.

 

How long does it take for a Scrum Master to be a great Coach

There is no fixed duration. Each Scrum Master learns at their own pace.

It may take anywhere from 2-6 years of dedicated learning + practice to develop a good range of coaching skills.

A good reference in this field is the ICF (International Coach Federation) - the most widely recognized body of Executive, Business, and Life Coaching.

The entry-level - Associate Coach takes roughly 1-2 years.

The third-level - Master Coach may take up to 8-10 years in the journey.

However, what is most important to become a great coach is to get started on your learning path today.

Remember the Chinese saying? - "The best time to plant a tree was 20 years ago. The second best time is now."

7 ways the Scrum Master can improve Scrum Team Communication

7 ways the Scrum Master can improve Scrum Team Communication

by | Apr 17, 2019 | Scrum Master

If your Scrum Team's performance matters, it NEEDS to have excellent communication.

In this article,

First, I will show you why strong communication within the teams is more important than ever.

Then, I will help you with strategies to improve your Scrum Team's communication.

 

Before we get into the importance of strong communication, let me share a quick story of John.

John, a Sr. VP of a financial services organization was leading a 400 strong group. The lack of positive work environment was his biggest concern. John wanted to address it as soon as he could. John formed a team to address this issue. They collectively resolved to create a healthy and positive workplace. After months of investigations, surveys, observations and team brainstormings, they nailed one reason that had to be improved - Communication.

John's organization isn't an anomaly. Various studies show that poor communication causes over a half of the projects to fail.

Effective communication is equally important for the success of a Scrum Team.

Scrum is a high-intensity team sport. Good communication is one of the essential elements to build a robust Scrum team.

Lack of communication or poor communication will invariably cause your Scrum team to fall apart.

Strong communication among the Scrum Team is an essential element for effective collaboration and co-creation of value.

If the communication within your Scrum Team is broken, don't let it be.

IMHO, Scrum Master should be the first person to observe and act if such conditions within a Scrum Team prevail.

 

Signs of poor communication

Here are 8 most common indicators that you as a Scrum Master can sense in your team with sample tips and examples:

1- Using a monologue over a dialogue.

Reflect: Watch out how the Product Owner talks at the Product Backlog Refinement meetings.

2- Disregarding feelings of others.

Reflect: Let the truth be told but are the team members considerate and empathetic?

3- Making personal comments during communication.

Reflect: Is every team member being accepted for who they are and for their unique personality?

4- Being Subjective/Vague.

Reflect: What is the progress towards the Sprint Goal in last 24 hours? Actively listen-in during the Daily Scrum.

5- Playing the blame game.

Reflect: Does the team have a shared ownership of the outcomes? Watch out the Retrospective from turning in to a place for blame games.

6- Resisting feedback

Reflect: Is the feedback being given and received constructively?

7- Lack of shared language of communication

Reflect: Does everyone on the team speak and understand the common language? Do they have a clear and transparent Definition of Done?

8- No new ideas coming up during discussions

Reflect: What's keeping the team from sharing their ideas? Is anything holding them back? Are the team members focused?

What are the possible consequences of poor communication?

 

Here are 10 most common consequences of lack of good communication within the team:

1- Lack of shared understanding.

2- Conflict.

3- Trust erosion.

4- Us v/s They feelings.

5- Wastage in the process. Over-processing required.

6- Getting things done becomes difficult.

7- Additional Formal approvals, sign-offs required.

8- Reduction in the team empowerment.

9- Self-organization becomes difficult, giving back way for top-down management.

10- Reduced product quality.

I've used the below strategies repeatedly with Scrum Team's to help them boost the level of communication.

7 Proven Strategies to Improve your Scrum Team Communication:

 

1- Improve Transparency:

Lack of transparency of artifacts and information hinders active communication. Identify which artifacts/information lacks transparency and how can it be improved. Enhanced transparency helps establish the context for communication and enables quick decision making.

Encourage the team members to practice and promote transparency.

Show them examples of transparency, it's advantages and how your team can benefit from it.

2- Facilitate Interactions:

Observe what is restricting the interactions and what is promoting. As a Scrum Master design your meetings and environment for face-to-face interactions among the team members.

The Agile Manifesto rightly calls out the preference for - People and Interactions over Process and Tools as it's very first value.

Say, if you as a Scrum Master observe that the use of a particular tool/method of communication is reducing the interactions between the team members, what would you do?

One simple approach you can try is to pause the use of that tool/method for a week. Observe if the interactions improve.

Try to find approaches that improve interactions. For example: If your User Stories are written on index cards - it'll prompt further communication v/s Detailed User Stories written in a multi-page document or an electronic tool.

3- Bring Clarity:

Clarity in the communication is crucial and directly correlates to the success of the Scrum team. As a Scrum Master, ensure that the team members understand the basic rules of the Scrum.

Team members must have clarity about their roles, responsibilities, their team's Sprint capacity, and the scope of the problem that needs to be solved. Having a clear idea about the dates that are important for the success of the product, the purpose of the product, the customer feedback, the action items from the Sprint Retrospective, etc. helps the entire team take shared ownership of the team's results.

4- Make Communication Visual:

I can't emphasize on this enough. A lot of miscommunication happens because what is told is not what is heard, forget about the understanding. Sometimes people are not able to clearly say what they want to and the listeners may end up understanding something completely different.

Making the communication visual is a great way to bridge this miscommunication gap.

Whiteboards, flip charts, sketch-notes, graphic notes, etc. enhance the richness of communication by making the discussion contextual to the tasks at hand and also help visualize the ideas. The use of visual aids allow for quick + crisp dialogue among the team members and rapid decision making.

This one is a low cost and high ROI investment.

Supply your team members with enough of the dry erase markers and erasers. Let their meetings (formal and informal) make use of whiteboards and flip charts.

Two developers drawing and discussing the architectural design of the code on a whiteboard is one of the most common scenes we might be familiar with.

Having plenty of whiteboards (fixed and portable) and flip charts near your team's working area prompts the team members to use them. The PO discussing User Stories with the Development Team members, User Experience Design conversations among the team members, technical design decisions, user acceptance testing as well as customer feedback - all of these conversations can be enhanced with the use of visual aids.

Whiteboards promote face-to-face interactions. The use of whiteboards will allow your team members to move away from wasteful passive communication to valuable rich communication.

Frequent use of the whiteboards IMHO is almost directly related to the number of quality conversations, and ideas your team members will be able to discuss.

5- Create Trust in the Environment:

Lack of trust among people will directly impact the communication and openness. All the process improvements will matter less in the absence of Trust.

If the team members are not comfortable speaking up, investigate the reasons.

Try to create an open environment where people feel safe to share their ideas and can ask questions without being judged.

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. - Scrum Guide 2017

Building trust in the workplace requires consistent efforts from everyone on the team. The Scrum Master can coach the team members to be consistent, responsible and truthful to build trust.

Building trust is a slow process. It also requires a high level of consistency in the behavior. However, the results of building high trust are far-reaching.

If you implement above three ways - Improve transparency, and facilitate face-to-face interactions using whiteboards, you can expect the trust levels within the work environment go a few notches up.

6- Unite People with Purpose:

If the people don't know why they need to work on something, if people are not excited about it, there is less motivation for them to participate fully. Disengaged employees will usually stay passive in the communication. Uniting purpose-driven teams becomes easy and yields long-term results.

It's important that the team members know the purpose that drives the product and the organization.

It doesn't hurt to repeat and remind everyone the purpose that binds the organization and drives their decision making.

The Scrum Master must ensure that every team member is directly able to interact with the customer.

Understanding how the product one is working on creates impact in the lives of the customers is highly motivating and massively rewarding in the long term.

7- Use Non-Violent Communication:

Understand the basic human needs.

 * Psychological Nurturance: food, exercise, rest, sex, shelter, touch.

* Safety: being able to show and employ one's self without the fear of negative consequences on the status or career" (Kahn 1990)

* Interdependence: acceptance, appreciation, community, enriching life, safety, empathy, honesty, love, respect, support, trust, understanding

* Freedom: the ability to choose one’s goals, values, plans

* Celebration: creation of life and goals fulfilled, celebrate wins and losses

When these needs are unmet, the resultant response is usually feeling of threat. In the condition of threat, the brain's normal logical reasoning function is taken over by Amygdala - a neurochemical responsible for fight or flight response in humans.

The usual communication style of people is to compete, judge, demand and diagnose.

The Scrum Master practices and teaches the team to practice Non-Violent Communication.

Benefits of Non-Violent Communication are:

  • Conflict Resolution: Get to the heart of conflict and disputes quickly, Improve cooperation and resolve the conflict.
  • Personal Relations: Deepen emotional connection. Get what you want more often without using demands, guilt or shame.
  • Organizational Effectiveness: Improve teamwork, efficiency and morale. Increase meeting productivity.
  • Business Relations: Strengthen employee morale and loyalty. Reduce stress and absenteeism. Maximize employee potential.

 

Marshall Rosenberg, the creator of NVC framework expressed it as more than a communication model. Below NVC elements offer a structural concept of the NVC process that leads to giving and receiving from the heart.

> Honestly Expressing how I am and what I would like without using blame, criticism or demands

> Empathically Receiving how another is and what he/she would like without hearing blame, criticism or demands

NVC focuses our attention on four pieces of information - irrespective of expressing or receiving,

Observations—Objectively describing what is going on without using evaluation, moralistic judgment, interpretation or diagnosis

Feelings—Saying how you feel (emotions and body sensations) about what you have observed without assigning blame

Needs—The basic human needs that are or not being met and are the source of feelings

Requests—Clear request for actions that can meet needs

 

Got Challenges?

Your team's context and challenges may be unique. Your people's communication preferences may be diverse. The communication skill level within your team may be extremely low. The motivation level of your people to cooperate, communicate and collaborate may be negligible.

The existence of all of these challenges warrants the need for an excellent and skilled Scrum Master.

A servant-leader who can facilitate the creation of an excellent communication platform for the team to benefit from and thrive.

 

The Scrum Master as a Servant-Leader

by | Apr 7, 2019 | Scrum Master

Scrum Masters - Servant Leadership is one aspect that can set an effective Scrum Master apart from the pack. Are you looking to be an effective Scrum Master?

In this in-depth guide, I explore the Scrum Master as a Servant -Leader, Servant-Leadership with the context of the Scrum Master role, the characteristics of a Servant-Leader and how you can apply these characteristics to become an effective Scrum Master.

A Servant-Leader desires to serve. A Servant-Leader serves first. This behavior is opposite to a traditional manager’s style which is to Manage/Lead first.

A Scrum Master is a Servant-Leader. Scrum Master serves the Team’s agenda, helps them grow and succeed.

Jump to Topics Below:

What is Servant-Leadership | Servant Leadership and Scrum | Servant Leadership and Scrum Master Role | Experts on Servant-Leadership | 8 Servant-Leader Behaviours for Every Scrum Master | Responsibilities of a Servant-Leader 

What is Servant-Leadership?

Servant Leadership is a philosophy and set of practices that are based on serving and caring for others, to lead. Servant Leadership behavior creates a more just and caring world by enriching people and building better organizations.

Robert Greenleaf defined a Servant-Leader as:

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. That leader significantly differs from one who is leader first, may be due to the need to acquire power, material belonging, control and authority within the organization.

The leader-first and the servant-first are two extreme leadership styles. There are a variety of shades between these two styles.

Robert Greenleaf popularized the Servant Leadership movement in 1970 through his article – The Servant as Leader. In which he coined the words "Servant-Leader" and "Servant Leadership."

 Servant Leadership and Scrum

How is Servant Leadership useful in the application of Scrum framework?

First, the 5 Scrum values - Openness, Respect, Commitment, Courage, and Focus, align well with the philosophy of Servant Leadership.

It's about your character and behaviors. How you practice what you preach to your people. Do you respect your people, show openness while listening to their ideas, display courage in keeping their needs ahead of yours etc.

The Scrum Master becomes the role model of practicing the Scrum Values and serves the team to be able to practice the same.

Second, The Scrum Master plays a key role in the success and failure of any team's Scrum implementation. Scrum Guide specifies that the Scrum Master is a Servant-Leader for the Scrum Team.

This is about people and serving them so they can grow and succeed. As part of the Scrum Master’s role, the Scrum Guide lists the Scrum Master’s service to the Development Team, the Product Owner, and the Organization. Scrum Master serves these roles to help them meet their goals and become successful.

Third, Scrum Master facilitates building a high performing team.

The team model in Scrum is designed to optimize flexibility, creativity, and productivity - let's call it effectiveness. - The Scrum Guide.

The Scrum Master helps create this vision of a high performing team. The Scrum Master helps remove impediments, shields the team from interruptions, helps them stay focused, and empowers them to make progress towards a better future every Sprint.

Fourth, Scrum is a team sport. Self-Organization and Team Collaboration are essential elements for the success of any Scrum implementation. This is practically not achievable in the presence of top-down, command-oriented management, and functional silos within organizations.

To enable self-organization teams must be free from a central point of authority. In the absence of any organizational authority and power, the Scrum Master allows space for the development team to self-organize.

Servant Leadership and Scrum Master Role

The Scrum Master is a Servant-Leader for the Scrum Team – Scrum Guide. To encourage Servant Leadership behavior, the Scrum Master role by design does not have organizational authority or power.

The Scrum Master is not a boss or an alternate title for a manager of the team.

The absence of organizational power, allows the Scrum Master to establish Psychological safety within the team. Which in turn empowers the team members and allows them to self-organize.

If the Scrum Master possesses organizational power, that limits the chances of establishing a safe environment.

A Servant-leader Scrum Master creates an environment where people can contribute and flourish. An environment where people are cared for and feel safe to express themselves. An environment where they've enough empowerment to make necessary decisions. Scrum Master is that leader for the Scrum Team.

Who does the Scrum Master serve? The Scrum Master serves the Development Team, the Product Owner, and the Organization in their endeavor to apply Scrum and get benefits from it.

A Scrum Master with her leadership enables the Scrum Team to become High Performing Team. Such that it can rapidly adapt to the changing customer needs and solve customer challenges.

If you are a Scrum Master who also happens to have organizational authority - aka responsibility of product delivery, the team members reporting into you, you make financial decisions, you write performance reviews, etc. observe your behavior closely.

Ask yourself:

If asked, will my colleagues and team members say that I serve them?

Whose agenda do I serve? Theirs or mine?

Am I able to justify the responsibility as a Servant-Leader Scrum Master?

How does Scrum Master's Servant-Leadership style work with traditional managers? The paradoxical style of Servant Leadership is difficult to enact for the traditional managers. Most managers tend to be comfortable with the leadership aspect, but not the servant aspect.

New Scrum Masters and Servant Leadership:

It's not uncommon for novice Scrum Masters to restrict themselves to being the servant or secretary of the Scrum Team.

First time and particularly untrained Scrum Masters typically limit their focus on setting up the meeting invites, arranging supplies, jotting down the meeting minutes, updating team's tasks on the task board, creating reports and sending out communications on behalf of the team members or PO etc.

They mostly miss exhibiting the leadership aspect. It doesn't have to be this way.

What do experts say about Servant Leadership?

"The difference between Servant-Leaders and other leaders manifests in the care taken by the servant-first-leaders to ensure other people's needs are being served. A quick test of the servant leadership is:

a) Do those who are being served grow as persons?

b) Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?

c) What is the effect on the least privileged in society?

d) Will they benefit or at least not be further deprived?"

The servant leadership is not about being submissive, letting go or giving in. It is about the genuine interest to serve others.

Inspired by “Journey to the East” by Herman Hesse, Greenleaf coined the concept of the Servant-Leader. In “The Servant as Leader”, Greenleaf said:

...the Journey to the East story clearly says: the great leader is seen as servant first, and that simple fact is the key to her/his greatness. Leo - the character in the story, was actually the leader, all the time, but he was servant first because that was what he was, deep down within.

Leadership was bestowed upon a man who was a servant by nature. Leo was a servant first.

If there is a single characteristic of the servant-leader that stands out in Greenleaf's essay it is,

The desire to serve.

Another very insightful observation by Greenleaf is that Servant-Leaders are Self-Aware. "Awareness is not a giver of solace. It is just the opposite. It is a disturber and an awakener.

Able leaders are usually sharply awake and reasonably disturbed. They are not seekers after solace. They have their own inner serenity”.

From a Scrum Master's perspective, Servant Leadership is about identifying and serving the needs of the Team and the Stakeholders.

8 Servant-Leader Behaviours for every Scrum Master

 

The characteristics of Servant leadership are inherent to some people. These characteristics can be further learned and such behaviours can be refined through practice.

How to apply Servant Leadership in my role as a Scrum Master? If you want to become effective at the Scrum Master role, you may begin with asking: How can I develop Servant-Leadership skills? For Scrum Masters to display Servant-Leadership, it is essential to develop and practice Servant-Leader behaviors.

Below 8 Servant-Leader behaviours combined make them highly relevant for the Scrum Master role. Applied to any team and organisational environment, these Servant-Leadership behaviours transforms the organizational culture to a caring, safe and high-performing culture.

 

Let's take a look at these behaviours

#1 Servanthood and Caring:

As a Scrum Master, you do not have any authority in the organization. You derive influence from your subject matter expertise of Scrum and by having the heart to serve your team and care for them.

As a Servant-Leader you seek to empower the team members and invite them in decision making. Your behaviour is of serving and caring. It enhances the growth of team members while improving the caring and quality of organizational life.

Is your emphasis on serving your team-members for their good and not just the good of the organization? If yes, then you sure are one effective Scrum Master.

#2 Empowering and Helping:

Are you concerned about the success of all stakeholders? Broadly stakeholders include employees, customers, business partners, communities, and society, including  those who are the least privileged.

Servant-Leader Scrum Masters believe that team members have an intrinsic value beyond their apparent responsibilities as employees. These Scrum Masters are deeply committed to the development and growth of each and every Scrum Team member.

During my work as a Scrum Master, I aimed to nurture the professional as well as personal growth of team members I worked with.

Let me share the story of Pat. Pat was one of our team members who had excellent business analysis and customer interview skills. Pat was going through some emotional challenges with his new wife. I invited him for a coffee one day. We briefly discussed his situation. I asked Pat, if he wanted my help? Pat showed interest and we setup time for three coaching sessions. We mutually agreed that the coaching will be intended to focus on how Pat can become aware of and possibly change his behaviour.

During our second session, I offered Pat to take a quick assessment to become aware of his own emotions. To understand the range of his emotions and what behaviour/situation, triggered the positive emotions and what triggered the negative emotion was first step.

Now Pat's aim was to identify the positive emotional triggers while he was with his wife and prolong those. Where as any triggers causing negative emotions and trauma were to be narrowed in duration and limited in intensity as much as possible. It wasn't easy or quick, however Pat was determined to change his situation.

Becoming aware of his emotions empowered him to identify how he can best deal with the circumstances. Pat would try to build up whenever he experienced positive emotions such as Joy, Hope, Pride, Inspiration, Awe, Gratitude, etc.

There are wide variety of opportunities where you can help your team members develop professional as well as personal capability and grow.

Think about what opportunities within your team exists this week where you can help your team members grow.

 

#3 Serving Team’s Agenda:

A Scrum Master as a servant-leader uses his capabilities and skills to help the team establish their agenda. The Scrum Master serves the team's agenda, not her own.

The Scrum Master does not impose any directions or mandate upon the team.

A Servant-leader Scrum Master instead, believes in Change by Invitation.

She invites the team to choose the goals and the direction. She invites team members to opt in to participate and keeps options open for anyone to opt out.

It is important to understand that if a person is titled as a Scrum Master but also carries traditional manager's responsibility to deliver a release, or to manage the team members etc, she'll not be able to truly serve the team's agenda. Such person will almost always end up making others follow her direction and agenda that she sets.

There is also a boundary to serving team's agenda. For example: If a Product Owner's agenda is to finish certain number of features by this Sprint however the team clearly sees that as not practical. Though you want the Product Owner to succeed, however, in such situation it your responsibility to shield the Development Team from the excessive pressure of the Product Owner. Often Scrum Masters give-in to the pressure and allow the PO to overload the Dev Team.

What do you think is the result in situations when the Development Team was asked to deliver more than they could practically deliver

a) A product having defects and poor quality

b) Stressed and overworked Team members from having to work extra nights and weekends

c) Accrual of Technical Debt

In any of the situation, can you say the Team's Agenda was served?

#4 Building Relationships:

Establishing and nurturing long-term relationships with all stakeholders, keeping the team-members in focus, helps them meet their fullest potential. If you are genuinely serving, caring and helping your team members grow, building relations with them will not be an issue. To build longer term relations, you would need to forgo short term approach/gains and allow for the things to settle.

Healthy relations with the team creates a synergy among the team-members and boosts team's performance and growth.

Is your emphasis on building long term and healthy relationships? If yes, you are on track.

#5 Being Humble:

Like a good leader, the Scrum Master stays humble and practices regular self-reflection. Counter to a traditional leader's pride, servant leaders exhibit humility in their behaviour.

Servant leaders don’t think less of themselves they just think of themselves less.

They have high self-confidence but very low situational confidence. If they are faced with a situation, their response would most likely be: I have the intellect to solve all the problems, but I don’t have all the answers and for that I need other people’s brain.

In today’s world where there is so much information and so many tools, its important to acknowledge that one person cannot know everything and that everyone needs or at some time will need his/her team members' help.

A servant-leader will not take pride in the moments of success but will surely accept errors in times of failure.

 

#6 Emotional Healing:

Your people are going through change all the time. There is uncertainty, and failures. Some of your people may have bruises. Many of them may go through emotional turbulences. Are you able to emotionally heal them? Offer your support?

As per Tuckman’s Team Development development model, team go through Forming, Norming, Storming and Performing phases. While your team is going through Forming, Norming and Storming phase of the team development, as a Scrum Master, are standing by your team during this time of change?

As a Servant-Leader, any emotional healing and support that you offer can go long way in building an environment of trust and care within the team.

 

#7 Being Empathic:

Being Empathic involves deeply connecting with the emotions of the other individual without judgement and critique. It is an essential behaviour of Servant-Leaders. Empathy starts with listening. Genuinely being present in the moment with somebody and listening with your whole self helps understand the other person's situation. Here the aim is to slow down and listen with the intent to understand the meaning behind the words, meaning of what is being felt, and what is not being said. Empathy connects two people by heart. Connecting with someone by heart is much more powerful than connecting only through brain.

For Scrum Masters who are not naturally empathic (count me in with you), being aware of and caring about others' emotions is the starting point of developing empathy. Empathically listening to what your team members say and acknowledging what you sense+hear.

Such as:

Elena, you seem to worried. How can I help?

David, I hear you are concerned about Matt's behaviour. What would you like to happen?

When you lend someone your empathic ears, they get it. They feel safe and comfortable to share even more.

Scrum Master through Empathy builds relationships, heals the team members, earns trust and gains influence.

 

#8 Being Ethical:

The moral component of the Scrum Masters must be strong. Being ethical relates to the way in which a servant-leader makes choices, disciplines herself and chooses the right thing to do in the service of the team. The Scrum Master may also encourage the team to self reflect and establish high standards of moral and ethical behaviour.

The team members constantly observe the moral basis of the servant-leader's actions and organizational goals and relate to them. If you as a Scrum Master have ingrained integrity and professionalism in yourself, it'll be possible to bring it in the team.

Often times, the Scrum Master may realize that the team needs to mature and they must be empowered, educated to handle their own meetings, hold each other accountable, collaborate with users and PO and deliver value. And time comes when the Scrum Master may not be providing the best value for the team and hence should decide to either step down from that role or move on.

Displaying this high level of ethics and courage to step down from one's role, to let go, is the best way you can become really effective at performing the Scrum Master's role.

Responsibilities of a Servant-Leader

What are the responsibilities of a Scrum Master as a Servant-Leader?

A ScrumMaster is a servant-leader whose focus is on serving the needs of the team members and those the team serves - the customer. With the goal of achieving results in line with the organization's values, principles, and business objectives

As a servant-leader, the ScrumMaster's responsibilities may include:

 

  1. Setting up Scrum framework in the service of the team, not as a way to commanding or micro-manage.
  2. Empowering and Guiding the Development Team on self-management.
  3. Leading the team through healthy conflict and debate on ideas.
  4. Teaching, coaching and mentoring the organization and team in adopting and using Scrum.
  5. Shielding the team from disturbances, external influences, and potential threats.
  6. Helping the team make visible, remove and prevent impediments.
  7. Creating transparency by radiating information via e.g. the product and sprint backlog, daily Scrum, reviews and a visible workspace;
  8. Encouraging, supporting and enabling the team to reach their full potential and performance.
  9. Nurturing a collaborative, supportive and empathic culture within the team.
  10. Constantly keeping the team challenged and away from mediocrity.
  11. Ensuring development, growth, and happiness of team members.

How to grow your leadership impact?

by | Apr 4, 2019 | Agile Leader

Improving your leadership impact is a holistic journey. There is neither a definitive step by step approach to it nor a single checklist of 7 ways you can improve your Agile Leadership Impact. While every leader's journey is unique, below I offer two actionable ways you can massively up your leadership impact.

Reflect and Adapt your Leadership impact:

One of the essential elements of being an Agile leader is that you constantly reflect and adapt your leadership impact on the people you lead. Pick up the mirror often and check your behavior, actions, and assumptions.

Evaluate regularly if people you lead are impacted positively and are benefiting from your leadership. Your intention to serve the people you lead, empower your people and develop them is important. However, if your actions are not aligned with their needs they have from you, your leadership impact is going to be severely limited. An easy way to address it and grow your leadership impact is to ask the people you lead.

Two Powerful Questions to upgrade your leadership impact:

1- What is my team's biggest challenge or pain point?

2- What can I do to make things better?

Grow Agile Leadership Impact

Optimize the Whole System:

Organizations are complex systems. The nature of problems within large organizations is also complex. Typically leaders take a local view, skipping the systemic view of the organization when making decisions.

To address whole systems - Leaders must develop an ability to recognize the whole system and make decisions that optimize the whole system rather the parts of it. Leaders who help others in the organization to see the whole systems are able to create a shared understanding of the complex problems. It allows these people to collectively develop solutions that go deeper than simply fixing symptoms to address the roots of the problem.

Build Leadership Capacity:

Everyone can potentially lead and everyone has the capability to play leadership role irrespective of the position they hold in their organization. However, leaders aren't created automatically.

One of the responsibilities of the leaders within an organization is to mentor future leaders. Future leaders can develop into becoming leaders only if they are entrusted with responsibilities and given opportunities.

If the leaders you've developed are easily able to transition into your responsibilities and take the organization further when you move out - consider that you've been an effective leader. To mentor and coach future leader and help them grow requires a Servant-Leader mindset.

Improving the leadership impact is a journey and requires cautious and dedicated effort.

I'm curious to know, what is your favorite way to grow your leadership impact?

 

Scrum Training

We offer public and corporate in-house, Certified ScrumMaster Training – CSM, Certified Scrum Product Owner Training – CSPO, and non-certification version of CSM and CSPO workshops. We offer corporate on-site workshops customized to your needs such as: Scrum for Teams, Experiential Scrum Master Workshop, Agile Boot-camp, Agile For Leaders, Agile Leadership, LeSS Framework Training, Facilitation and Agile Coaching Workshop, and Kanban Workshop.

Top 21 Scrum Master skills | Essential ScrumMaster Skills

Top 21 Scrum Master skills | Essential ScrumMaster Skills

by | Mar 27, 2019 | Scrum Master

The use of artificial intelligence in product development and corporations is growing significantly. Repetitive tasks will no longer be done manually. With the help of AI we'll be able to automate even the cognitive tasks to a certain extent. If every enterprise small and large can automate most of their tasks, then what could be the factors of a competitive advantage?

In this rapidly evolving market, having a high performing, adaptive and innovative teams will be a competitive advantage for any organization.

Scrum Framework specifically identifies Scrum Master as a role that is responsible to create high performing, Agile teams.

A Scrum Master who is able to help build high performing and innovative Scrum teams, and coach people can be a valuable asset for the organization.

Can the AI replace the ScrumMasters? Can AI products develop Scrum Master skills and perform the tasks and responsibilities of a Scrum Master?

Well, to a certain extent. Those Scrum Masters who only perform mundane tasks, write meeting minutes, create reports and enter data in the electronic tool will see themselves get replaced by AI bots soon.

 

I think irrespective of the technological advancements there will still be a need of skilled Scrum Masters. An effective Scrum Master can help Scrum Team deliver results that are an order of magnitude better than mediocre Scrum Teams. Though the responsibilities of the Scrum Master may adjust with the time.

Great Scrum Masters will definitely contribute towards improving the business agility and helping organizational system as a whole.

The real-world challenge I see most organizations face today with the role of the Scrum Masters is - Developing Scrum Masters that have the required competencies and skills to perform the job well. Most Scrum Masters underperform due to lack of full range skills.

Below I list top 18 Scrum Master skills that'll be essential for Scrum Masters to stay effective even in 2020.

I also invite you to contribute 3 top Scrum Master skills that should be part of this list.

Top Scrum Master Skills:

    1. Systems Thinking: Ability to see the interplay of various components and resultant overall system. Helps avoid local optimization and enables the Scrum Master to take a holistic view of the complete organization as a system.
    2. Adaptability: This skill is at the core of being an effective Scrum Master. If the Scrum Master can herself adapt swiftly to the changing organizational system, and team's needs, she will be able to inspire the same behavior within the team.
    3. People Skills: Interpersonal skills are essential skills for a Scrum Master to be able to deal with the different personalities and demands of the team members, the PO, and the stakeholders. Bots will not be able to understand the complex human behavior in near future to be able to deal with it effectively.
    4. Complex Problem Solving: Product Development involves various elements that dynamically change and create complexity. Scrum Master must be able to handle complex situations and address problems in the complex domain. One example is when dealing impediments caused by external teams not directly known to the Scrum Team.
    5. Lean Thinking:Most organizations have processes and policies full of waste. The Scrum Master must develop this skill to observe and help the team identify + remove any waste in the process and create lean approach to develop and deliver customer value.
    6. Agile Mindset, Growth Mindset:Setbacks and failures are part of the game when trying new ideas and conducting experiments. The Scrum Master must teach the team to accept failures and encourage them to keep learning from the experiments. Adapting Agile Mindset sets the Scrum Master in a position to be able to help the Scrum Team.
    7. Creativity:The Scrum Master must become creative when helping the team solve impediments, designing Sprint Retrospectives, bringing change ideas, etc. The SM helps the Scrum Team utilized creativity to explore the uncharted territories and to experiment creative product/market ideas. The iterative and incremental approach of Scrum maximizes feedback and minimizes risk, the Scrum team's intense collaboration makes the team environment conducive to creative ideas.
    8. Empathy:The ability to understand the other person's situation and show them that you care.
    9. Asking Questions:More damage is done by Scrum Masters telling the team what to do and giving them the answers. An effective Scrum Master may empower the team to think and solve their challenges. It takes years of deliberate practice to move from telling and to move to asking questions. With practice, the Scrum Master can develop the skill to ask powerful questions.
    10. Collaboration:Before the team accepts your advice to collaborate, they'll judge if you collaborate with your peers and other Scrum Masters within the organization.
    11. Facilitation:The skill to facilitate meetings, decision making and facilitating change is the most common skill every Scrum Master must develop.
    12. Rapid Decision Making:The Scrum Master must develop the skill to be decisive. The empirical approach of making decision empowers the SM to rapidly make decisions based on what is known. Transparency promotes rapid decision making and the Scrum Master ensures the artifacts are transparent. It is important that the Scrum Master teaches the development team and the Product Owner to make fast decisions and avoid analysis paralysis to ensure a working product increment is delivered every sprint.
    13. Leading and Facilitating Change:The Scrum Master must develop finesse in leading change. Inspiring the team members to continuously improve their processes and practices requires excellent facilitation skills + inspiration. The Scrum Master is a change agent that guides the Scrum Team and the Organization on their journey to improve Agility, learning, and growth. The Scrum Master gets everyone's buy-in to make the change and ensure the change is positive in nature.
    14. Focus:Enterprises are full of distractions. The Scrum Master has to be intentional in avoiding the distractions to be able to stay focused on working on the highest value tasks. The SM also teaches the development team to stay focused on their Sprint plan to accomplish the Sprint goal.
    15. Performing with Flow:Staying focused can help the Scrum Master work on the highest impact tasks. The Scrum Master must keep challenging herself as well as the team they coach to handle increasingly challenging goals. The satisfaction of accomplishing bigger and complex goals adds further momentum and helps the Scrum Master perform with the flow.
    16. Negotiation:Creating a win-win situation is the only way to win in the long term. Negotiation is also termed as Interpersonal decision making. The Scrum Master should facilitate such decision making among the Product Owner and the Development Team, the PO and the Stakeholders, and the Scrum Team and the leadership. You miss this skill and you'll see that the team is being asked to work on more user stories than they can pick. The Product Backlog size is ever increasing.
    17. Intrinsic Motivation:Developing a high level of interest and staying fully engaged in the tasks at hand is the responsibility of every individual as a professional. If the Scrum Master is able to connect with a purpose and perform with the flow, she is further able to develop intrinsic motivation. The motivation that is not dependent on external rewards, bonuses or recognition. The Scrum Master is able to drive meaning from the work and remains motivated to handle complex challenges.
    18. Emotional Intelligence:The ability to self-regulate, be self-aware and socially connect with the team members at a deeper human level allows the Scrum Master to build a long-term relationship and create a healthy work environment. Due to the rapidly changing nature of complex work that requires intense collaboration among the entire team, it is important that the Scrum Master is adept at emotional intelligence.
    19. Which Skill should be listed?
    20. Which skill should be listed?
    21. Which skill should be listed?

    I need your opinion to add 3 top Scrum Master skills that'll be valuable in 2020.

Scrum Master Skills, ScrumMaster Competencies

6 Benefits of Good User Stories

6 Benefits of Good User Stories

by | Sep 16, 2017 | User Stories

In previous two articles, we discussed:

Becoming user centric with User Stories and

How to write good User Stories

In this article, lets understand the fundamental benefits of good User Stories. I challenge teams that I coach to strive to realize all of these User Story benefits.

While you read the article, I encourage you to think: how can you get maximum value from applying User Stories? It could be a competitive advantage for your team!!

Don't forget to take your User Story Benefits Assessment at the end of this article.

Benefits-of-Good-User-Stories

Without further ado, here are the

Good User Story Benefits: 

 

1. Highest Value Delivery:

This User Story Benefit is the mother of all benefits. Done well, User Stories help deliver the highest value by focusing on small and immediate customer needs.

Traditional product development teams may spend months on a single function such as analysis, design, implementation etc, carrying a significant amount of work in progress without delivering anything that is directly valuable to the customer immediately.

How could you take the old school requirements approach and turn it upside down?

Agile Teams break down user needs into small features or tasks that can be implemented and delivered from few hours to few days. The ProductOwner actively prioritizes these user stories in terms of user value, risk, and business value to significantly increase the value delivered by a team within first few sprints.

Delivery of highest value early in the product development allows the Product Owner to:

a) Start earning returns early.

b) Reduces the amount of investment that the organization needs put in - as the return from the product starts to pay for the new feature development at some point during the development.

c) Significantly increase the ROI.

 

2. Fosters Collaboration:

Good User Stories due to their minimalist characteristic, inherently give way to collaboration among the product development team, the Product Owner and the users of the product. While the traditional teams depend heavily on detailed documents and electronic tools, most Agile Teams collaborate with users to plan, implement and deliver customer value.

Minimal writing of the user's needs encourage the team members to talk to the user(s) or the Product Owner when they are ready to implement a UserStory. These discussions allow room for diverse business-technical perspectives to come to light and gives way for creative and innovative ways of solving customer's needs.

 

3. Brings User Closer:

By focusing on delivering highest customer value with each user story, the Agile teams are compelled to regularly connect with and collaborate with end users. Minimally written detail also encourages for the team members to talk to the user.

The team members directly connect with the user to understand the user's perspective, challenges, pain points and opportunities that need to be addressed. The team members also get early feedback from users by demonstrating implemented User Stories as soon stories are DONE.

In case if you haven't read yet, check out my article - Becoming User Centric with User Stories

 

4. Building Blocks of the Product:

With each customer value delivering User Story, the product is built incrementally. Building the product incrementally allows to rapidly adjust it to a new direction. When sliced in smaller ideas to experiment, user stories allow for quick implementation and user feedback.

With each successfully implemented feature, the product gets shaped and the value of the product keeps increasing.

User Stories allow for easy addition and removal of features from the Product.

If the Product Owner decides to remove a non-performing feature from the product, it becomes easy to immediately toggle off a feature that was built as a small user story.

During development, when a user story acceptance criteria do not pass, the Product Owner can exclude that one story and still release rest of the features to production.

 

5. Boost Transparency:

Written collaboratively on index cards, User Stories increase transparency among with the team member, Product Owner, and stakeholders. The index cards remain visible to everyone and allow for better collaboration and faster decision making.

Improved transparency also increases the Trust within the environment.

Order of User Stories creates transparency about,

a) the priorities set by the Product Owner and

b) the customer segment / persona that is being addressed through a particular user story.

If any story has dependencies and is stuck, the impediment becomes immediately visible to all.

Transparency reduces a lot of waste from the process and improves team's effectiveness.

It is not uncommon for teams transitioning from traditional software development practices to Scrum, to write user stories as long documents.

Prompting these teams to store (freeze) these long written stories in electronic document repository or a tool. Most of the tools are not designed to radiate information or improve transparency. Severely reducing the transparency of User Stories and related information.

Any practice that hampers the transparency effectively slows down a team and increases churn.

The most effective tools - Index Cards and Sharpies are not meant for writing long documents.

Improved Transparency is a serious advantage teams can get from user stories. Higher transparency could be a game changer for teams new to Scrum.

 

6. Shared Understanding:

How can better User Stories create shared understanding? Unlike the traditional approach where the business team writes requirements and hands over the documents to the development team to implement, the Agile approach is for the Product Owner and the Development team members to collaborate and collectively develop, refine, and split the user stories.

Working collaboratively improves the shared understanding of:

a) what is expected by (need of) the user and what is feasible from technology and business perspective.

b) what is intended by the Product Owner and what is understood / implemented by the development team.

7. Reduced Risk:

Bonus benefit number 7. There is one more important User Story benefit that is Reduced Risk.

Most traditional teams are not equipped with and lack proactive measures of reducing risk.

Effective User Stories by creating transparency, improving collaboration, creating shared understanding and orienting the teams to focus on customer needs, eliminates various potential risks such as - lack of communication risk, technical risk, financial risk, business risk, etc.

 

While getting all these user story benefits would be sexy, many teams have asked me questions such as:

> Are these user story benefits achievable?

> Do other teams get these benefits?

> Does any team fully realize all these benefits?

> What are usual challenges that prevent teams from getting all these benefits?

To help you explore your own answers, I've created User Story Benefits Assessment. In about a minute, you can self-assess and get instant scores.

 

Take the User Story Benefits Assessment now! Just scroll to the end of this page to take the assessment.

 

I just want to say, many times the appreciation of these User Story benefits come only when any risks arise from not having these benefits.

 

Actionable Tip: Let me invite you to identify and share in comments below - potentials risks for your product and team if these benefits of good user stories are missing.

 

Evaluate the User Story Benefits You Get Today!!

Evaluate and get your score now!!

Disadvantages of User Stories

Yes, while the User Stories are good and beneficial to a team's agility, it also carries certain disadvantages.

Compliance Needs - Should you need a requirements document for compliance needs - User Stories will not suffice in most cases. Though I would highly recommend you first talk to your auditor or compliance team proactively before making a call on this.

Knowledge Transfer - Should a major shuffling happen within your team or suddenly 2-4 team members leave your team and new members join - User Stories will not help with the knowledge transfer. Well, neither do the detailed requirements do it fully. At least index cards won't be sufficient in this case to get started. Some team member or the Product Owner will need to take out time to get the new team members up to speed.

Interpretation - Minimal detail subject the User Stories to different interpretations. It may sometimes happen that the team members may miss having a detailed conversation on every aspect of the story. This may invite assumptions and interpretations which may cause errors.

 

 

The Scrum Master as a Coach – Kamlesh Ravlani

by | | Agile Coaching, Scrum Master | 0 Comments

Coaching is one of the essential skills required for a Scrum Master to be effective. Coaching along with Facilitation and Teaching skills enable the...
Read More

7 ways the Scrum Master can improve Scrum Team Communication

by | | Scrum Master | 0 Comments

If your Scrum Team's performance matters, it NEEDS to have excellent communication. In this article, First, I will show you why strong communication...
Read More

The Scrum Master as a Servant-Leader

by | | Scrum Master | 0 Comments

Scrum Masters - Servant Leadership is one aspect that can set an effective Scrum Master apart from the pack. Are you looking to be an effective...
Read More

How to grow your leadership impact?

by | | Agile Leader | 0 Comments

Improving your leadership impact is a holistic journey. There is neither a definitive step by step approach to it nor a single checklist of 7 ways...
Read More

Essential Building Blocks of an Agile Organization

by | Sep 7, 2017 | Enterprise Agility, Product Development

Creating cross-functional and self-organizing Teams is one of the essential elements of building an Agile Organization.

Both aspects require significant effort & focus. These also don't happen naturally, particularly in organizations led with Industrial Age style of organizational structure and management.

Scrum identifies these as essential aspects and recognizes a specific role - Scrum Master. Scrum Master is responsible for helping the team and the organization achieve Self Organization and improve cross-functionality within the team.

In fact, Scrum Guide specifies it as the first aspect of the Scrum Master's service towards the Development Team.

The existence of organizational power and authority significantly limits the potential of self-organization, hence the Scrum Team is designed to not have any organizational authority and power by any of its members.

The Scrum Master doesn't carry any authority and organizational power, as well as commits to serve the Team's agenda.

Any Scrum Master that doesn't explicitly let go of authority and power, and does not commit to serving the team's agenda, would counter to one of the primary purposes of the Scrum Master role.

Such situation is not Scrum, as the organization won't fully realize the intended benefits of implementing Scrum.

An Agile Organisation is a learning organisation. The Scrum Master helps the teams with creating, transferring and sharing the knowledge and with inspection and adaptation at regular interval.

How to Write Good User Stories? User Story Examples

by | Sep 4, 2017 | User Stories

write user story, writing user stories

Why care to write good User Stories?

Similar to what the developers say - the best code is no code, the best User Stories are not written, they are told.

Mastering the art of writing good user stories isn't easy. Writing User Stories with just enough information that entices further communication and promotes collaboration is difficult. Most people tend to write more, considering useful User Stories to be mini versions of requirements documents.

Written well (read - written minimally), good User Stories become easy to understand and implement for the Scrum Team. Writing user stories that are small, and crafting user stories that are valuable, could in most cases solve one of the biggest challenges of the Scrum Teams - delivering shippable product increment every Sprint.

As discussed in my article becoming user-centric with User Stories - A User Story is a promise for further communication. Communication that should happen between the Development Team and the Customer or the Product Owner to create a shared understanding of the user's needs.

When crafted well, User Stories form the building blocks of a successful product envisioned by the Product Owner and desired by the customer.

In traditional product development environment, the Product Owner or Business Team would write detailed requirements they want to be implemented. The team would simply implement these requirements to the extent they understand it. Agile teams use User Stories and challenge this rationale.

User Stories require identifying who (a user) exactly will use the feature being asked to develop and specifying what benefit the user will get. This helps remove ambiguity and offers clarity in understanding the story (need) of a User.

A user story card may outline “why” - the benefit, “who” - the user and “what” - the feature or action.

The closest term for the User Story as used in Scrum is Product Backlog Item (PBI). PBI may refer to User Story, Feature, Technical Enhancement as well as change required in the feature.

What does Writing User Story mean for Scrum Roles?

In order to understand what makes a good User Story, it is important to understand what does the User story mean for everyone involved in writing+implementing user stories and their contribution.

Product Owner

For the Product Owner, User Stories are a way of putting user's needs, wish list items, hypothesis and everything else required of the product on a set of cards. The Product Owner collaborates with the development team to refine user stories. The PO orders these user story cards in order of the customer value, business priorities and risk for the development team to work on. User Stories also help the PO initiates the conversations with the Development team to create shared understanding about why, what needs to be implemented, who will benefit from it and how.

Development Team

User Stories open avenues for the Development team to get closer to the user's need, who will benefit from it and formulate how they would implement it to achieve the desired outcome. User stories also help with tracking the progress of the development within a sprint and create transparency within the Scrum Team. It helps plan the sprint.

Scrum Master

The Scrum Master ensures that the User Stories are transparent and that the team members and the Product Owner have a shared understanding of the User stories. If the Product Owner and the development team are bound by written contracts called requirements documents or the User Stories and are not collaborating, the ScrumMaster can facilitate communication and collaboration.

Scrum Master would take responsibility to help everyone understand the importance of keeping the user stories small, clear, concise, being flexible and allow for the most relevant user needs to emerge while discovery and development.

Most novice ScrumMasters end up doing just the opposite. They make sure the Scrum Team writes detailed user stories (kind of mini requirements documents), police around to ensure the electronic tool is filled with detailed descriptions, every possible acceptance criteria is listed and all 16 types of user story fields are filled.

User Stories encourages the Product Owner and the development team to collaborate with the user and to stay close to what the user needs. Scrum encourages collaboration by face-to-face communication. This makes using User Stories a logical fit (as a practice) with the Scrum framework.

 

Why do Teams Write Detailed User Stories?

I think the biggest reason for writing detailed user stories is - old habits.

However, many reasons compel teams to write detailed user stories such as:

  • Lack of Trust - Require sign-offs and approvals,
  • Traditional Mindset - Need proof,
  • Requirement Writing Experts, Business Analysts on the team,
  • Geographical distance between the PO and the Dev Team - Lack of transparency, need for approvals,
  • Regulated Environment - Healthcare, Banks, and Government domains require compliance with regulatory norms.
  • Client-Vendor Setup - Contracts, Need for approvals, CYA.
Writing User Stories

Detailed written requirements minimize the need for collaboration within the team and actively prevent the customer requirements to emerge during the development.

Writing detailed user stories is the 1st step to stifle collaboration within the Scrum Team.

A relevant question I recently asked on our LinkedIn Page about long & written documents is worth contemplating:

What if the #requirements documents writers ??,? #status #report creators, #ppt creators and internal #diagrams creators were to seek feedback on the cost ?of writing each page v/s its usefulness ???

Artifact Transparency allows regular inspection. The Scrum Master may help the team analyze if a one-page document will meet the need instead of writing a 10-page report.

The Scrum Master is responsible to identify smells that induce waste, and prevent agility and help the Scrum Team address the root cause of such dysfunctions.

User Stories Templates

The need for templates and standardization stems from simple and repetitive work.

In Complex domains, it is essential for teams to adapt practices based on the context. Standardization of any practice or artifact would actively resist adaptation.

The Product Owner of a Scrum Team I was coaching, recently asked me - What is the best User Story Template used by Scrum Teams?

Well, writing better user stories is not dependent on the user story template used. More important than finding the best User Story template, is, every team must establish a common language that everyone on the team understands. If the essentials are met, the user story template used doesn't matter much.

A simple User Story template, that originated from Connextra and widely used by product development practitioners involves these three elements:

As a <<USER>>,

I want <<FEATURE>>,

So that <<VALUE>>.

This simple User Story template narrates the value for the user. The primary focus of writing User Story using this template should be the Business value that the Product Owner is trying to achieve through the implementation of a particular User Story.

An adaptation of above user story template, that makes the focus on Business Value explicit, is below version:

To realize <<VALULE>,

as a <<USER>>,

I want <<FEATURE>>.

When to write a User Story?

What is the pre-User Story phase?

A pre-user story condition could be a:

  • Hypothesis,
  • Feature Idea,
  • Customer Need,
  • Business Opportunity,
  • Change in Markets,
  •         Experiment.

Any of the above may trigger the need for a new user story.

There is no specific condition required to write a new user story. Anyone including Scrum Team members and Stakeholders may write a User Story when they find a need and share it with the Product Owner.

How to Write User Story?

Here are three characteristics that help craft effective User Stories.

1. Identify the Business Value:

To make a product successful, the Product Owner tries to maximize the business value delivered. In order to maximize the business value, it is important to identify: a- the Business Value, and b- the effort required, associated with a user story.

Knowing the Business value helps the Product Owner order the User Story with the highest Business Value at the top of the Product Backlog.

Example: For a new e-commerce website to launch, the highest Business Value will be when a new user is able to buy an item from the website. Let's take a closer look. Traditionally, the line of thought for the sequential functionality being made available would have been in the below sequence:

1a. New user can register on the website

User Story Example 1:

As a First time visitor to the website,

   I want to be able to register on the website,

   So that I can browse and buy listed products from the website.

 

1b. Registered User can Browse items listed

Writing User Story Example 2:

   As a Registered Website User,

   I want to be able to browse listed products from the website,

   So that I can make my choice and buy a listed product from the website.

 

1c. Registered User can add items to the cart

User Story Example 3:

   As a Registered Website User,

   I want to be able to add items to the cart,

   So that I can buy a listed product from the website.

 

1d. Registered User can make payment for the items added to the cart.

User Story Example 4:

   As a Registered Website User,

   I want to be able to buy listed products,

   So that I can use the product I buy.

 

Looking closely at the User Stories above tells us that the website visitor would not be able to make a purchase on the e-commerce website till the time User Story 4 is implemented and made available at the website.

The Human brain thinks sequentially, and step-by-step. It is evident from the above User Stories that the Product Owner writing user stories is looking at the website from the perspective of the end user and trying to depict his/her sequential line of thought.

Now if you wear the hat of a Product Owner, you must think about how can the highest Business Value be delivered early?

That requires prioritizing user stories in a way that the highest Business Value User Story finds its place at the top of the Product Backlog.

If you thinking out of the box and not sequentially as the human brain is trained to think, here is an alternate option to craft the User Story:

Writing User Story Example 5:

   As a First-time visitor to the e-commerce website,

   I want to be able to buy a listed product,

   So that I can use the product I buy.

 

This means that the First-time visitor to the e-commerce website should be able to make the payment as a guest user without having to register - User Story Example 1.

Does "Buying a product" has more value than "Browsing products" - User Story Example 2?

Sure, any day!

Adding chosen products to the cart - User Story Example 3 is a nice to have and allows the user to buy multiple items at the same time. However, being able to buy the product - User Story Example 5 without registering, browsing or adding the products to the cart has the highest Business Value.

2. Identify the “Who”:

It’s important and imperative to identify the Customer being served before you think of writing a User Story. One of the most common mistakes done by novice Scrum Teams is to generalize the User segment being served by a User Story.

Identifying a narrow and specific User segment being served by the User Story, helps reduce the size of the User Story.

The User Story becomes specific and clear as to who - which customer, is being targeted. Many Scrum teams use User Personas for their product and specify a particular persona while writing a user story.

Example: I had once worked on a capability that was available to all Credit Card users on the desktop. Our team was developing the set of features to make the capability available on an App for Tablet (iPad) and Mobile users.

The team started with this User Story format:

   As an App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

Now we had an option to split the user story as a “Mobile App User” and “Tablet App User”. The Product Owner prioritized the “Mobile App User” over the “Tablet App User” since that User Segment had higher volume and more business value. So, the PO chose to go with:

   As a Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>

Then, we had an option to re-write the user story in to two User Stories - as an “Andriod Mobile App user” and “iOS Mobile App user”. The Product Owner prioritized the “iOS Mobile App user” over the “Android Mobile App user” since that was a User Segment with even more business value. So, we chose to go with:

   As an iOS Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

In addition to this, we had Silver, Gold and Platinum Credit Card, holders. The Product Owner prioritized the “Platinum Credit Card holder” since that was a User Segment with highest business value. Our user story looked like:

   As an iOS Mobile App user holding a Platinum Credit Card,

   I want <<FEATURE>>,

   So that <<VALUE>>.

This is the level where the Scrum team was clear as to who was served by implementing the User Story.

Identifying a very specific user segment provides clarity, flexibility, creates shared understanding, reduces risk and results in improved ROI for the efforts.

 

3. Understand the “What”:

Communicating clearly “what” will be delivered as a part of the User Story is crucial too. This is the part of the User Story where the customer has an avenue to communicate his/her perspective on what s/he needs – feature, enhancement, etc.

Example: In another implementation that I had a chance to work on, we were implementing the approval system of a large Custodian bank. Can you believe they were dealing with Billions of Dollars yet the process was pretty much manual?

Anyways, using this Business Process Management tool, various departments involved would review and approve the application from a Sub-custodian bank to become a registered Sub-custodian to the Custodian based in the United States. The end goal was to create an automated system where:

  1. The interested Sub-custodian would apply online with all the details and documentation required by the Custodian, once that is done
  2. The Custodian would do multiple levels of review within the departments that existed in the Custodian bank.
  3. The application would then be sent to the regulatory body for their approval.
  4. Once approved by the regulatory body, the Custodian Bank would revert to the Sub-custodian requesting additional documentation required to formalize and close the registration process with the Custodian Bank.

As it appears, this was a huge task by itself. The team decided to break it down into bite-sized features. Although the team was going to use an off the shelf product with most of the functionalities required, yet there was a lot of customization required at each step.

With the array of features required to be implemented, we chose to first target the internal audience with the Custodian bank and the various departments within the bank whose approval was required as part of the registration process. We narrowed down the User to one department within the whole approval flow. We then decided to drop off the option of being able to attach the documents to the approval flow. Now the User Stories looked like:

   As a Registration team member,

   I want to be able to review the Sub-custodian application,

   So that <<VALUE>>.

 

   As a Registration team member,

   I want to be able to approve the Sub-custodian application,

   So that <<VALUE>>.

 

   As a Registration team member,

   I want to be able to reject the Sub-custodian application,

   So that <<VALUE>>.

 

These were easier to understand and also gave the Scrum Team a perspective on what’s being sought. Each User Story was written (crafted) in a way that it could be implemented within a Sprint. Breaking it down to the specifics removed ambiguity. Keeping the User Story minimal encouraged the Development Team members to go talk to the customers or the Product Owner.

Summary:

Nailing the “who”, “what” and “why” of the User Stories, making them minimalistic, small, transparent, and valuable makes them viable survivable experiments for the Scrum team.

Minimally but well-written User Stories allow the Scrum Team to learn fast and inspect and adapt, resulting in reduced risk and better alignment with customer needs.

 

Do you have a story to share that your team crafted well and delighted the customer?

Agile Assessment – Check How Agile is your Team? Fast!!

Agile Assessment – Check How Agile is your Team? Fast!!

by | Aug 29, 2017 | Agile Team

Agile Team Assessment by Agile For Growth

At one point during agile transformation, you may look at your practices, your team, and the organization and may want to assess the Agility of your team and the Organization. Taking the Agile Assessment may help you explore –

> How Agile are we?

> Are we really Agile?

> Are we doing it right? etc.

Well, the benefits you reap from Agile Transformation should actually give you the indication of how Agile you are. What are the typical benefits you should see if your teams have improved their agility?

What are the typical benefits you should see if your teams have become Agile and improved their agility?

  • Improved ability to respond to changing customer needs
  • Reduced time from idea to experimentation to products/features that customers can use
  • Improved alignment of your products with your customer’s needs resulting in growth opportunities for your business
  • Better alignment within the organization. For example Among marketing-product-delivery teams.
  • Significant reduction of waste from processes
  • Boost in Employee Engagement and Morale

It is realistic that while transitioning from traditional product development to Agile development, teams, and organizations improve at a linear pace in most cases. Their performance improves in few areas but remains lackluster in others.

It is important that the team members are aware of their strengths and the areas that need improvement. To help teams with such evaluation, there are a plethora of commercial Agile assessments available in the market. Most commercial surveys and assessments focus on the frameworks, processes and practices aspects leading the teams in the opposite direction to where the teams should focus on.

While creating the Agile Assessment, my primary focus was to help you to shed all the layers of the processes and practices and go back to the core of being Agile.

Agile Assessment assess your team agility with respect to proven areas such as:

Principles behind the Agile Manifesto

Human Psychology and Motivation

Keys to Successful Google Teams

I’ve tried to make the entire assessment as simple as possible. On top of that, you get Instant scores – sent to your email id. No waiting. Don’t get fooled by the simplicity of this powerful assessment. Give it a try now!

After the Agile Assessment

After you take the Agile Assessment, you’ll instantly get an email from me with your scores. Watch out for my email. Just in case if you don’t find it in your inbox, look for other folders – Promotions, Updates, Spam – depends on your email provider. Add my email id to your contacts.

Based on your scores, I also help you to understand your scores and the potential organizational factors responsible for your scores. I share relevant pointers and ideas to try within your team to improve your scores.

Follow up

To get best results and growth, I encourage you to take this assessment again after one month and compare your scores.

It’ll take less than 10 minutes to take the Agile Assessment. Give it a try now!

Becoming User centric with User Stories

Becoming User centric with User Stories

by | Jul 27, 2017 | Product Development, User Stories

storytelling user story

Traditional product development creates functional barriers that separate the product developers from the users of the product. The reason user stories were used in the Extreme Programming was to connect the product developers with the real-world stories of the customers and users. Stories help the developers understand the pain areas of the users and the opportunities of delighting the users and making them feel awesome.

Today, for most of the teams, User Stories have just become a form in an electronic tool which someone should fill in so that it can enter the Sprint planning, get developed and shipped. Instead of learning the art of storytelling, Product Owners and Teams are often found searching for the perfect ways to fill the User Story templates . In this process, the real intent of the user stories is somewhat lost.

To benefit from the User Stories, teams must go back to the original intent of connecting with the users and learning the user’s latent pain and gain areas, understand their emotions and how a product can help make users’ life easy.

Medtronic, a Minnesota-based medical technology company has institutionalized the art of this storytelling. Every year at the annual employee gathering Medtronic brings in users to share their life transforming stories with all the employees. Leaders at Medtronic use every opportunity to share User’s Stories in their messages. They use both positive and negative stories to reinforce to employees its guiding principle of “Customers First”.

User Stories help product developers understand the impact they have on the people they serve. Understanding the story of the users also empower the developers to find the best way of solving a challenge.

User Stories act as a bridge between users and product developers.

User Stories are most popularly used today in the Agile software development field particularly with the Scrum Framework.

Often index cards are used to write User stories that focus on the benefit to the user. It consists of one or more sentences in the everyday language or the language of the end user (user perspective) that captures description of the story and benefit to the user. It also captures criteria for its acceptance. It helps in shifting the focus from writing about requirements to discussing about the benefits to user(s).

User story card captures the ‘why’, ‘who’ and ‘what’ of a potential feature or hypothesis in simple and concise way. Often limited to detail which can be hand-written on an Index card.

When used with Scrum Framework, a user story should essentially will be small enough so it can be delivered within one sprint and valuable enough so that a user can use it and provide her feedback.

INVEST

Bill Wake came up with INVEST acronym to emphasize what makes up a good User Story:

 

 

INVEST

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Independent

User stories are easiest to work with if they are independent i.e. it shouldn’t overlap in the concept. The team may creatively break the technical dependencies as often as possible to create independent stories.

Negotiable

A good user-story should be negotiable. It should capture the essence of the requirement and not the detail hence allowing the team and the Product Owner to negotiate the scope and approach of developing it.

Valuable

A good user-story needs to be valuable to the customer. It should clearly answer the “why” so the resulting product increment becomes valuable for the user an essential condition for a user to be able to use the product and share feedback. This criterion also draws attention to avoid creating stories that does not deliver customer value such as – story that only focuses on single function such as database work, or platform enhancement or only UI tasks.

Estimable

A team should understand the story well enough to be able to estimate how much time, effort will be required to deliver a testable and acceptable feature. The estimates allow the Product Owner to forecast the budget and delivery timeline.

Small

A good story typically represents at most a couple of person-days’ worth of work. If the work exceeds a week, the team may have difficulty in delivering a user story hence running into the risk of not delivering it within a sprint. Delay in delivering the user story delays the feedback again increasing the associated risk of failure.

Testable

A good user story is testable, i.e. everyone should well understand how the completion of the story will be verified by a user or a proxy of the user that is a Product Owner. It should be understood well enough so that tests can be written and performed. Acceptance Criteria helps establish this user acceptance testing. In case if a story can’t be tested, its scope should be reframed in a way so it can be tested.

Creation of user-story

Once I was coaching a team that was transitioning from traditional product development to implement Scrum. It was their first day after I facilitated a 3 day Agile Team Boot camp for their entire team. Their Product Owner – Jane was excited to get started with user stories and creating their first product backlog. They did have the knowledge that it’s going to be different from their usual approach of writing long multi-page requirements documents. The knowledge had to be put in to practice. Jane and the team members had to cautiously put in efforts to get away from their way of thinking and behaviour of writing long requirements documents and dumping those to their shared document repository and hope that everyone on the team will read, understand and deliver product as intended. That was never the case.

At the beginning of the working session, we did a 2-minute activity to recall points they learned about the User Stories during the boot camp. During this activity, Sri one of the team members stood up and recalled:

A User Story card is a promise for a conversation

Not a mini requirements document, not a requirement itself, a user story card is a promise by the Product Owner for a conversation with the team members when the team picks up a story for implementation. Alistair Cockburn, shares how it was done by the Chrysler C3 team in 1998 when it was first used:

A programmer would pick up a story card, walk over the Customer, and say, “Tell me about this”, then go over and program it up, and come back again and ask, “Like this?”, and back and forth until it was done. The ‘requirements’ were never written down, they communicated in discussion and feedback.

Not writing down requirements felt uncomfortable for Jane in the beginning. Jane and the team members collectively formulated and wrote (new) user-stories. Stakeholders were invited to contribute to writing user stories based on their needs. During the workshop, the intent was to write down high level 1-2 line description of each user need, feature, and hypothesis. There were lot of queries and as we navigated through the workshop, each query was discussed, explored and addressed.

Below I list some of the common User Story queries that I’ve heard.

One of the common way teams write user stories is in the form of:

As a <user type>, I want to <some goal>, so that <benefit>

A crisp user story should answer the following three questions:

  • As a <type of user>: Who are we building it for, who the user is?
  • I want to <action>: What action the user should be able to perform, what is the intention?
  • so that <benefit>: Why are we building it or what value it brings to the user?

 

Three common user story errors to avoid

  1. Missing User: If a story doesn’t specify the user, it is most likely going to miss the user’s story. If there is no user and no story the result is far from being a User Story. As simple and silly as it sounds, this is one of the most common error teams make. You may see it in the stories that say something like – As a DBA, I want to….., As a System Admin, I want to….., etc. It takes cautious effort on part of the Product Owner to pro-actively connect with users, listen to their stories and bring them to the team. Each user story may specifically address one user or a group of users with similar needs. Get this one right and you are on the track.

 

  1. Too much detail: This one is again resulting from the old mindset of writing down detailed requirements. The Product Owner tries to write every detail in the user-story forgetting the fact that a user story is a promise for a conversation not the requirement itself. Too much detail often dilutes the purpose of the User-story and hinders the team members from having the conversation with the product owner. Writing down too much detail in the user story can conveniently hide the fact that users’ input, users’ story has not been considered before formulating the user story. Necessity to write down too much detail may also be an indication of lack of sufficient trust in the environment – often prevailing in the cases where the Product Owner and the team members work from different geographies.

 

  1. Answers ‘how’ and misses ‘what’: A user-story should define what the product should do and what benefit should it yield not the specific approach of how it is achieved. The approach to achieve a user story’s intended outcome should be left for the development team to identify. After the high-level task of writing user stories was completed, the next task was refinement. To refine user stories, split larger stories, add description, write acceptance criteria etc. The team invited the Scrum Master to setup a follow up session to refine the user stories.