Loading...

Follow 3Back Scrum & Agility Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

The primary goal of Scrum Mastering[1] is to enable a Well-Formed Team (WFT). Ideally, a Well-Formed Team[2] would take on most of its own facilitation and coaching. However, some Teams get stuck in earlier stages of maturity that we describe as Collective Conflict Avoidance.

Collective Avoidance is a norm that needs to be thoughtfully and progressively challenged to grow WFT behaviors. Perhaps paradoxically, until a (relatively) stable Team can successfully work through enough uncomfortable situations together (with facilitation), the Team will not achieve enough trust to collaborate effectively.

To help a Team progress through development and cultivate a Well-Formed Team, we often have some tough challenges to work through as a Scrum Master[3] or Team Facilitator[4]. Our purpose in this blog post is to provide a few clues on how to go about building a Well-Formed Team.

Observations

It begins with becoming an expert observer of your Team’s behavior.

Let’s explore what a good Team feels like so that we can hone our empathy instinct.

  • Good Teams Feel: Fun, happy, hopeful, engaged, and energetic.
  • Poor Teams Feel: Mad, sad, worried, overworked, tired, and rushed.

We’ve all seen this behavior in our workplace, and intuitively we all know how the good Team behavior and the poor Team behavior feels to each of us. However, as a Scrum Master or Team Facilitator, we need to dig deeper to realize the “how” and the “why” behind our Team’s behavior. But first, let’s discuss how Team behavior spreads.

Mirrored Behavior Spreads

Humans are social creatures, and as a result, much of our behavior is picked up by simply watching how other humans react. Without thinking about it, we often mirror behavior from Team members and spread that behavior along. Mirroring behavior is especially tempting when we follow leadership or power figures. For better or worse, Team members spread mirrored behavior rapidly.

We spread mirrored behavior by taking social permission from each other and then justifying the correctness of our thought by way of an agreement with our peers. We cannot be wrong because our peers agree; therefore we must be right. Without much thinking, and often without our best interest, we adopt a social behavior and corresponding viewpoint — this pattern is particularly attractive when it supports a desire for avoidance.

So, as Scrum Masters and Team Facilitators, we must combine the reality of mirrored Team behavior with our goal of enabling a WFT. We need to take steps to heighten our awareness of how our Team is behaving, and if it resembles the above list as to how poor Team’s feel, we need to step in and facilitate.

6 Signals That Indicate Your Team Has Avoidant Behavior

What are some easy signals we can detect when Scrum Mastering a Team? We can start by opening our ears and closing our mouths. Then, simply listen for the signals.

If you hear…

  • Signal 1: “Nothing, no one, never…”
    • (Team Members speak in definitive statements about the outcome.)
  • Signal 2: “Bad, terrible, worst ever…”
    • (Team Members don’t even consider other outcomes.)
  • Signal 3: “I know what will happen and…”
    • (In a situation where Team Members cannot possibly predict the future, they assume there will always be a negative outcome when dealing with a complex problem.)
  • Signal 4: “I know what they are thinking … and it is (not good).”
    • (Team Members become mind readers and make sweeping negative conclusions.)
  • Signal 5: “It’s not our fault. We are a victim…”
    • (Team Members are quick to point blame at the process, person, or circumstance.)
  • Signal 6: What others have you seen or heard?

Then, your Team needs facilitation.

So, What Should A Scrum Master Do?

First, realize that we are trying to help Teams open up and connect in ways that leverage the diversity of their thinking. When people are told they need to be positive (instead of real), they tend to suppress the first thing that comes to mind. So simply saying to your Team, “Have a positive view,” will be counterproductive. You need your Team to be real and focus on the realities as they exist. Otherwise, you risk a reaction that shuts down good, deliberative dialogue and decreases the Team’s capacity for more complex arguments.

Then, Challenge Your Team
Does your Team have the facts straight? Are you, as Scrum Master, really sure ‘X’ is true? Can you test it? You need to introduce a new focus or shift the Team away from pointless speculation and avoidance to the current reality of what your Team really knows.

The goal is to help your Team think cleaner and more factually. Teams oriented towards cleaner and factual thoughts become healthier. Data cannot make a decision but, it can help us think better, cleaner thoughts based on feedback from reality. You need to get the group to mirror behavior that focuses on data and facts to drive cleaner thought process — the mirror can work both ways. The trick is to get it working for the Team in a healthy way.

Rome Wasn’t Built In A Day
As Scrum Master, it can be hard to be patient with your Team’s development. Poor Teams weren’t built in a day, nor were good ones. A Scrum Master’s process must be deliberate, and this takes time. Habits of behavior can be deeply entrenched, and Team members are often unaware they are acting against their collective interest, so you need to help them gain awareness and, ideally, help each other focus on the facts. The Team norm then becomes fact-based or evidence-based decision making.

Complex problems[5] require creative solutions. And, creative solutions are harvested from a process rich in argumentative complexity. Without this process, your Team will resign to simplistic results, groupthink, or conflict avoidance – all of which will undermine confidence and produce substandard results.

Keep your ears open to the signals around you and facilitate through them. Let your Scrum Master goal of enabling Well-Formed Teams guide you.

If more tailored Scrum Mastery coaching might help you and your Team, we’ve got just that.

Talk to us about our onsite coaching and consulting!

Notes and Sources

1-5 “Scrum Mastering,’ “Well-Formed Team,” “Scrum Master,” “Team Facilitator,” “Complex Problems.” Accessed April 25, 2019. https://scrumdictionary.com.

The post 6 Signals of Collective Conflict Avoidance appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
3Back Scrum & Agility Blog by Marc Applebaum, Phd - 2M ago

How do we recognize when the way we’re  “doing Scrum“ is impeding our Agility?

Two alternative scenarios are possible:

  1. The Team has fully internalized Agile[1] practice in the past but now seems to be sleepwalking through the Ceremonies[2]: the Team’s Agile practice has gotten stale, we’re sleepwalking through Scrum.
  2. The Team hasn’t experienced Agile practice yet, and Ceremonies feel stale because they’ve not yet come alive.

This post addresses Scenario A–we’ll address B in a future post.

Sleepwalking

“Our Team used to really click. We collaborated well, worked creatively. Now our work feels flat.”

First of all, recognize that what you’re experiencing is a normal occurrence in any Team’s life cycle. It’s a well-known psychological principle that even good habits tend to become mechanical over time. Habits give our lives rhythm and familiarity in the world that can feel chaotic. Having a rhythm at work is absolutely necessary; on the other hand, when our habits become entrenched, it’s easy to slide into autopilot.

The Neurology Of Autopilot

Recent research published in the Proceedings of the National Academy of Sciences[3] argues that our capacity for autopilot is an evolutionary adaptation. Our ability to switch into autopilot gives us the “cognitive flexibility” we need to cope with complexity. Simply put, zoning out helps us divide our attention so we can focus on one issue while mindlessly doing another.

We can take the train to work or drive to the grocery store without much thought because the route is familiar and we don’t need to think about it. As a result, researchers argue, “a considerable portion of our daily lives comprises learned, automatic, reflexive or habitual behaviors under specific contexts in stable environments,” as opposed to more awake, spontaneous responses to the particular situation we’re facing in the present moment.

Autopilot is useful for many moments in life, like making your early morning coffee! But autopilot becomes an impediment when we need to be fully present, awake, and responsive to a new situation—-that is, when our success relies on our ability to detect changes in the environment and adapt to them.

When a Team’s work starts to feel stable and repetitive, we can lapse into sleepwalking, regardless of what methodology we use, no matter how inspired or sophisticated it is. Our very success might lull us into sleepwalking. This can happen even with Scrum, the whole purpose of which is to help deal with reality in Scrum.

We’re all human. So sometimes Ceremonies can become a kind of empty ritual that we do because it’s Tuesday or the third week of the month, not because we feel they’re helping us deal with reality the way they used to.

Detecting When The Team Is Sleepwalking

How do you reawaken Scrum for a Team that knows what it feels like to work together in a natural way? As a Scrum Master[4] or a Stakeholder[5], your challenge is to help the Team deal with recognizing where it’s really at.

  • We act like we’re on autopilot in Ceremonies. We’re tempted to check email or make mental shopping lists.
  • Review[6], Planning[7], or Retrospectives[8] feel like checking a box because nothing new ever happens there.
  • When we’re in Ceremonies, we can’t wait to get back to our “real jobs.”
  • If conflicts come up, we’re more than happy to skip a Ceremony because we know we won’t miss much.

The emotional tone these items share is boredom or even resentment! And for good reason: we have made Scrum into a burden. Or putting it in a more responsible way, we have made Scrum practice into a burden. Whoever is responsible, let’s set aside the blame game for a minute, and just acknowledge that something’s not working.

Scrum Mastering

How do you wake the Team up, out of sleepwalking? It may be that circumstances do this for you: maybe the Team hits a wall and is jolted into alarm, a disturbing sense that what we’ve been doing isn’t working: a great opportunity for you as a Scrum Master to help the Team deal with Reality.

If the Team doesn’t hit a crisis that sounds the alarm, then you as Scrum Master become that alarm clock! How? By using provocative Retros to return to Reality, to awaken Curiosity about the challenges faced by the Team, to focus on a bite-sized chunk of work, if the autopilot response is overwhelming.

Notes and Sources

1-2 “Agile,” “Ceremonies.” Accessed February 20, 2019. https://scrumdictionary.com.

3 Vatansever, Deniz, David K. Menon, and Emmanuel A. Stamatakis. “Default Mode Contributions to Automated Information Processing.” PNAS. November 28, 2017. Accessed February 20, 2019. http://www.pnas.org/content/early/2017/10/18/1710521114.

4-8 “Scrum Master,” “Stakeholder,” “Review,” “Planning,” “Retrospective.” Accessed February 20, 2019. https://scrumdictionary.com.

The post Sleepwalking Through Scrum appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The daily life of a Scrum Master[1] is anything but mundane. Play along with one Scrum Master as she facilitates, coaches, and runs interference all in the name of becoming a Well-Formed Team[2].


Download a PDF Version of This Infographic

1.  Arrive at the office 1/2 hour in advance of the Team, coffee up, tidy the Team’s workspace and remove distractions.

2.  Facilitate 15 minute Daily Standup[3] to Plan the Day.

  • Where are we right now?
  • Where do we want to be?
  • So, what should we do to day to get there?

3.  Help the Team remove an Impediment[4] that was surfaced during Standup by 2 pair-programming developers.

4.  Remind the PO[5] to help the Team Extract Stories[6] from the devOps Chore[7] Epic[8].

5.  Set up a training session for the DevLead to teach new developers the best practices of TDD (Test Driven Development).

6.  Select activity and focus points for upcoming Sprint Retrospective[9].

7.  Meet with PO to review top-prioritized Stories in the Backlog[10].

8.  Have lunch with the devOPS SME[11] to discuss Swarming[12] availability for next Sprint[13].

9.  Update the Information Radiator to show the latest information on the current Buildup[14].

10.  Grab an afternoon coffee with PO and discuss how to recognize and deal with Technical Debt[15] that built up during the rush feature Release[16].

11.  Run interference when a Stakeholder[17] comes into the Team room and insists the Team work on a Story not in the current Sprint.

12.  Develop a blog outline about coaching Team dynamics.

13.  Stop by a Team Swarm on a new Story’s Doneness Criteria[18] and have the PO move a finished Story to Done[19].

14.  Meet with 2 of the Stakeholders to clarify Stories that need to be captured for the Fridge[20].

15.  Hit the local Scrum User Group Happy Hour.

Learn more about what it’s like to be a Scrum Master with tips like How To Kick Impediments to the Curb, Servant Leadership And Scrum Mastering, and The 7 Essential Roles To Be the Best ScrumMaster

As Always, Stay Agile.

Notes and Sources

1-20 “Scrum Master,” “Well-Formed Team,” “Daily Standup,” “Impediment.” “PO,” “Extract Stories,” “Chore,” “Epic,” “Sprint Retrospective,” “Backlog,” “SME,” “Swarming,” “Sprint,” “Buildup,” “Technical Debt,” “Release,” “Stakeholder,” “Doneness Criteria,” “Done,” “Fridge.” Accessed March 9, 2019. https://scrumdictionary.com.

This blog was updated on 3/20/19.

Are you looking for more information on how to help your Well-Formed Team? Download 3Back’s white paper, The Well-Formed Team and get started today!

Your Team will thank you.

The post A Day In The Life Of A ScrumMaster appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

We were humming along as a Team; suddenly it feels like everybody’s got two left feet. What’s going on?

Sometimes when a Team hits a rough patch, after a period of really working well together, it’s hard to understand what went wrong? We’ve faced tough challenges before… this feels different.

How? Not only are we feeling unclear about how to tackle the new challenge; we actually don’t seem to be doing ordinary stuff very well anymore! Morale has taken a hit, we’re more frustrated with ourselves, and with each other, maybe someone on or outside the Team is even starting to question whether the Team has peaked, and changes need to be made? You know–bring some new blood onto the Team, or divide up the Team and let people move on to new projects to “keep things fresh.”

Of course, there’s no one-size-fits-all recipe for a Team losing its sense of comfortable workflow and collaborative rhythm. This post is dedicated to exploring the possibility is that the Team is temporarily regressing because it’s facing a developmental challenge.

Scrum Mastering Tip

Here are some sample questions a Scrum Master can use to unpack what’s going on in a Retro[1]:

  1. What’s different about the challenge we are facing today from the challenges we faced in our previous work?
  2. Let’s assume some level of uncertainty about our success is normal for any project. What doubts do we have about our ability to succeed in the current project? How can we address bite-size pieces?
  3. Has our Mission[2] changed? If yes, what’s different about our new Mission? If we’re not sure whether our Mission has changed, what questions do we need answered? Who do we think can provide those answers?
  4. Is there anybody or anything outside of the Team we’re tempted to blame for our current predicament? If we put all our blaming statements out on the table in an un-edited way, and take stock of them, which can we agree are well-grounded, and which might be overblown?
Underlying Theory

There’s an old psychological principle at work here, something psychoanalyst Ernst Kris (1936) called “regression in the service of the ego.”[3] The core idea is that as Psychologist Danielle Knafo argues, sometimes it’s necessary to take a developmental step backward in order to take two steps forward – and it is this temporary regression and re-integration that makes possible “more connection, invention, and vision.”[4]

Renewed connection, invention, and vision is precisely what an Agile Team is seeking in confronting a never-before-countered challenge. This psychological principle is true not just for individuals but for collaborative Teams, in the following way.

“The more trust, integrity, and cohesion a Team has, the more it is able to allow itself to undergo temporary periods of regression in order to discover a renewed, newly empowered ability to creatively cope with challenges.”

Sometimes we naturally have to take a step back, developmentally, to move forward. Neurologically, something needs to get re-wired, new connections are needed, and that’s not just a personal challenge, it’s a challenge we face together.

Even the alchemists in the middle ages were familiar with this principle; they called it solve et coagulum–dissolving what’s become lead, so to speak, in order to reform it as gold. What this means is that it feels like the Team’s structure–in terms of its well-established knowledge, habits, and familiar ways of working together–has come to a screeching halt in the face of a big new challenge.

Learning To “Dance” Again

In a situation like this, we may very well feel like the Team is broken! We can’t move forward in the way we’re used to, and it may feel like everything we were sure about has gotten thrown up in the air. You could say it’s like the Team feels like everybody’s been asked to learn a new dance step at the same time, and we are all stepping on each other‘s feet as well as our own! Everybody’s got two left feet.

At this point, we need two things to move forward: first of all we need patience: for ourselves, and from our leaders and Stakeholders. And this patience can only be invited when we are able to name the challenge we are facing and begin to take on bite-size pieces of it. At first, it might feel like we’re learning to walk again as a Team. In a way that’s true, but if we can work through this gray zone together, the odds are that all of the flow and teamwork we had established before will re-emerge, but at a new level.

Could your Team use some help learning to “dance” again?
We’ve got coaching for that.

As Always, Stay Agile.

Notes and Sources

1-2 “Retro,” “Mission.” Accessed February 20, 2019. https://scrumdictionary.com.

3 Kris, Ernst.1936. “The Psychology of Caricature, in Psychoanalytic Explorations in Art”: 173-188. New York: International Universities Press.

4 Knafo, Danielle. “Dancing with the Unconscious: The Art of Psychoanalysis and the Psychoanalysis of Art.” Routledge, 2012..

The post One Step Back, Two Steps Forward appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Scrum coaching and training usually focuses on strengthening your Dev Teams’ collaboration, empowering Scrum Mastering and Product Ownership. These ingredients are all required for Scrum Teams to achieve high-quality results.[1] But a key ingredient is missing in creating the conditions for success: what 3Back calls Mission Protection.[2]

Definition: Mission Protection is Executive Leadership’s ongoing, public commitment to safeguarding the Scrum Team’s ability to achieve their mission.[3]

Examples of leadership providing Mission Protection:

  • Protecting the Team against “backchanneling”[4]by preventing influential Stakeholders[5] from pulling Team Member’s energy off the mission and weakening the Team’s focus
  • Ensuring the Team gets help from SME’s[6] to achieve their mission
What’s Backchanneling?

“This should only take you a few minutes….” We’ve all heard that before! It’s the usual preamble when a Stakeholder is “asking” you to add extra, unplanned work into the current Sprint…work that was never prioritized in refinement[7], hasn’t been written into a clear Story, assumes an effort[8] that hasn’t been properly sized, and doesn’t take account of any hidden dependencies or implications by the so-called “quick fix!”

Definition: A backchannel is a covert route for passing information. Backchanneling in a business happens when a Stakeholder leverages his or her influence behind the scenes with a Team member in order to shortcut the Team’s work queue to advance their own priorities.

It’s normal for leaders in a business to use their influence to move their own priorities forward. However, Scrum can’t work if the agreements between Business Owners, Product Owners, Dev Team members, and Scrum Masters are regularly broken by Stakeholders’ end-runs. When rule-breaking is the norm, you’ll quickly end up with Scrum In Name Only. In other words, the business has taught Team Members to be cynical about Scrum ceremonies and Team Agreements[9], because what really drives the Team’s workstream is not the Backlog[10]or Sprint Planning[11], but the demands of powerful Stakeholders.

Well-Formed Teams And Backchanneling

Backchanneling can be even more toxic if your Scrum Team’s maturing toward self-organizing behaviors that we call a Well-Formed Team.  If the Dev Team’s working well together, their Scrum Master is helping them identify and resolve impediments, and the Product Owner is actively engaged in providing inputs to the Backlog and feedback on the Team’s work, BUT Team members are constantly interrupted by high-level stakeholder requests…then the Team will continually be pulled off its core mission and will eventually discard WFT principles as unworkable in your business environment.

Why Does The Mission Need Protection?

Even when a Scrum Team has clear Agreements about how stories get into the Backlog and from the Backlog into Sprint Planning, if a senior Executive shows up at a developer’s cube with a personal request for work–the famous “quick fix”–the developer may feel it’s impossible to say “no” or “later.” But bending to these social pressures quickly becomes a norm and saps the Team’s focus and energy for the Mission.

Businesses are human networks, and their lifeblood is relationships. No one likes to disappoint, particularly if the requester is the 900-pound gorilla! Sure, formally we have ground rules for how stories get submitted. But informally, everybody knows it’s not healthy for your career to say “no” or “later” to the big Kahuna (who might even be your CEO).

Missions need protection because, if they’re unprotected from the heavyweights in the business, the Team’s attention will be eaten alive by “urgent” requests coming from those heavyweights. Including your Founder and CEO!

Checklist: Is your Mission protected?

If Missions are Protected…

  1. Each Mission has an identified Business Owner at the VP or EVP level and has charged a single identified Business Owner with Product Ownership for the Backlog.
  2. The Mission’s Business Owner is available for frequent-enough Reviews with the Team to have a good sense of the Team’s progress.
  3. The Business Owner supports the Team by communicating the importance of the Mission to other Executive peers and encourages SME’s to support the Mission as needed.
  4. C-level, EVP, and VP stakeholders feed urgent requests into the Teams’ Inbox, empowering Product Owners and the Team to prioritize–rather than jumping the queue with fire drills.
  5. The Business Owner actively intervenes to hold Stakeholders accountable if they try to shortcut Backlog Refinement by backchanneling, and bring them into the process.
Learn How 3Back’s 1-day, Onsite Discovery Workshops Help Your Team Protect The Mission.
  • Objective assessment of your Scrum Team’s health, maturity, and empowerment
  • Detailed, real-time feedback that guides your Team
  • Customized tools to align your business to maximize results
Request a Discovery Workshop Now.

As Always. Stay Agile.

Notes and Sources

1-11 ”Results,” “Mission Protection,” “Mission,” “Backchanneling,” “Stakeholders,” “SME’s.” “Refinement,” “Effort,” “Team Agreements,” “Backlog,” “Sprint Planning.” Accessed October 12, 2018. https://scrumdictionary.com.

The post To Empower Your Scrum Teams, Provide Mission Protection appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Scrum coaching and training usually focuses on strengthening your Dev Teams’ collaboration, empowering Scrum Mastering and Product Ownership. These ingredients are all required for Scrum Teams to achieve high-quality results.[1] But a key ingredient is missing in creating the conditions for success: what 3Back calls Mission Protection.[2]

Definition: Mission Protection is Executive Leadership’s ongoing, public commitment to safeguarding the Scrum Team’s ability to achieve their mission.[3]

Examples of leadership providing Mission Protection:

  • Protecting the Team against “backchanneling”[4]by preventing influential Stakeholders[5] from pulling Team Member’s energy off the mission and weakening the Team’s focus
  • Ensuring the Team gets help from SME’s[6] to achieve their mission
What’s Backchanneling?

“This should only take you a few minutes….” We’ve all heard that before! It’s the usual preamble when a Stakeholder is “asking” you to add extra, unplanned work into the current Sprint…work that was never prioritized in refinement[7], hasn’t been written into a clear Story, assumes an effort[8] that hasn’t been properly sized, and doesn’t take account of any hidden dependencies or implications by the so-called “quick fix!”

Definition: A backchannel is a covert route for passing information. Backchanneling in a business happens when a Stakeholder leverages his or her influence behind the scenes with a Team member in order to shortcut the Team’s work queue to advance their own priorities.

It’s normal for leaders in a business to use their influence to move their own priorities forward. However, Scrum can’t work if the agreements between Business Owners, Product Owners, Dev Team members, and Scrum Masters are regularly broken by Stakeholders’ end-runs. When rule-breaking is the norm, you’ll quickly end up with Scrum In Name Only. In other words, the business has taught Team Members to be cynical about Scrum ceremonies and Team Agreements[9], because what really drives the Team’s workstream is not the Backlog[10]or Sprint Planning[11], but the demands of powerful Stakeholders.

Well-Formed Teams And Backchanneling

Backchanneling can be even more toxic if your Scrum Team’s maturing toward self-organizing behaviors that we call a Well-Formed Team.  If the Dev Team’s working well together, their Scrum Master is helping them identify and resolve impediments, and the Product Owner is actively engaged in providing inputs to the Backlog and feedback on the Team’s work, BUT Team members are constantly interrupted by high-level stakeholder requests…then the Team will continually be pulled off its core mission and will eventually discard WFT principles as unworkable in your business environment.

Why Does The Mission Need Protection?

Even when a Scrum Team has clear Agreements about how stories get into the Backlog and from the Backlog into Sprint Planning, if a senior Executive shows up at a developer’s cube with a personal request for work–the famous “quick fix”–the developer may feel it’s impossible to say “no” or “later.” But bending to these social pressures quickly becomes a norm and saps the Team’s focus and energy for the Mission.

Businesses are human networks, and their lifeblood is relationships. No one likes to disappoint, particularly if the requester is the 900-pound gorilla! Sure, formally we have ground rules for how stories get submitted. But informally, everybody knows it’s not healthy for your career to say “no” or “later” to the big Kahuna (who might even be your CEO).

Missions need protection because, if they’re unprotected from the heavyweights in the business, the Team’s attention will be eaten alive by “urgent” requests coming from those heavyweights. Including your Founder and CEO!

Checklist: Is your Mission protected?

If Missions are Protected…

  1. Each Mission has an identified Business Owner at the VP or EVP level and has charged a single identified Business Owner with Product Ownership for the Backlog.
  2. The Mission’s Business Owner is available for frequent-enough Reviews with the Team to have a good sense of the Team’s progress.
  3. The Business Owner supports the Team by communicating the importance of the Mission to other Executive peers and encourages SME’s to support the Mission as needed.
  4. C-level, EVP, and VP stakeholders feed urgent requests into the Teams’ Inbox, empowering Product Owners and the Team to prioritize–rather than jumping the queue with fire drills.
  5. The Business Owner actively intervenes to hold Stakeholders accountable if they try to shortcut Backlog Refinement by backchanneling, and bring them into the process.
Learn How 3Back’s 1-day, Onsite Discovery Workshops Help Your Team Protect The Mission.
  • Objective assessment of your Scrum Team’s health, maturity, and empowerment
  • Detailed, real-time feedback that guides your Team
  • Customized tools to align your business to maximize results
Request a Discovery Workshop Now.

As Always. Stay Agile.

Notes and Sources

1-11 ”Results,” “Mission Protection,” “Mission,” “Backchanneling,” “Stakeholders,” “SME’s.” “Refinement,” “Effort,” “Team Agreements,” “Backlog,” “Sprint Planning.” Accessed October 12, 2018. https://scrumdictionary.com.

The post To Empower Your Scrum Teams, Provide Mission Protection appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Scrum Mastering is a servant-leadership role. That’s a given. The phrase servant leader, first coined by Robert K. Greenleaf in his groundbreaking essay, The Servant as Leader, defined the role as focusing “primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the ‘top of the pyramid,’ servant leadership is different. The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.”[1]

That sure sounds like Scrum Mastering. But, what does that look like, exactly? How does the Scrum Master function as a servant-leader to enable and empower people to do their jobs? It comes down to 3 servant-leader roles, each of them responsible for ensuring Scrum is understood and correctly applied.

The 3 Servant Leadership Roles of a ScrumMaster

1. Team Facilitator (TF):

The Team Member who facilitates the Team Members’ self-organization (on a daily basis) to help them

Every Team must have a Team Facilitator, who is often a technical contributor, as well.

2. Agile Coach (AC):

A person who works with the Scrum Team to help them improve their skills. The skills might be technical or non-technical, and improvements are typically achieved through training and/or mentoring.

The Agile Coach often works with the Team Facilitator[3] to

  • Help the Team Members understand, implement, and improve their use of Scrum and Agility; and
  • Help the Team identify its Kaizen every Sprint.[4]

Every Team must have access to an Agile Coach as needed; this usually requires one Agile Coach for every 2-10 Teams, with 5 being the ‘sweet spot.’

3. Change Agent (CA):

A person who helps the Organization adopt, implement, and sustain Scrum and understand how best to support and work with Scrum Teams, including organizational design. There needs to be at least one Change Agent per Organization. The Change Agent is usually also an Agile Coach[5] (with expertise in organizational behavior), and is considered the ‘senior Scrum Master’ in the Organization.

Looking for more real-world tips on Scrum Mastering? We’ve got a Scrum Zone conference for that. As Always. Stay Agile.

Notes and Sources

1 Greenleaf, Robert K. The Servant as Leader. Westfield, IN: Greenleaf Center for Servant Leadership, 2008.

2-5 “Team Kaizen,” “Team Facilitator,” “Sprint,” “Agile Coach.” Accessed March 15, 2018. https://scrumdictionary.com.

The post Scrum Handbook: Servant Leadership And Scrum Mastering appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Many large organizations find it hard to deliver valuable Results[1] to their Stakeholders[2]. Their size makes it difficult to adapt to the fact that both the realities of delivery and the Stakeholder’s minds change in unexpected ways. That’s when systematic scaling of Scrum becomes critical to an organization’s success.

When An Organization Scales, There Are 4 Main Forces In Play:
  1. The need to decompose into multiple interacting Teams so that decision-making can be layered and decentralized to avoid overloading decision-makers (the problem the Product Management Scrum Team solves in the above infographic)
  2. The need to communicate across Teams to Cooperate, Coordinate, and Collaborate
  3. The need to centralize common functions and features to leverage economy of scale and become more efficient
  4. The need to occasionally decentralize for effectiveness.

A successfully scaled organization looks like one whose structure scales in response to the forces that currently affect it.

Looking for more tools to successfully scale your organization?
We’ve got a Scrum 3.0 Conference for that.

As Always, Stay Agile.

Notes and Sources

1-2 “Results,” Stakeholder.” Accessed Accessed March 15, 2018. https://scrumdictionary.com.

The post How To Do Large Scale Scrum [Infographic] appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Stakeholders[1] are the reason we develop Product[2] in the first place. Stakeholders are those people that have needs, wants, and desires. (In an IT setting, these may be referred to as desirements, a processing task or type of output that is desired, but not absolutely necessary.) As a Scrum Team, we are trying to identify work that satisfies our Stakeholders. Stakeholders often (or maybe never) seem to really know what they want and even when they see something they want, they often change their minds. Figuring out what will truly satisfy a Stakeholders desire(s) takes a persistent effort of trial and error.

Stakeholders are vital to the Team’s success, as they review the Team’s Product and provide ongoing feedback. There are many people that are interested in the Product, but not all of them are Stakeholders – some are merely Interested Bystanders[3]. Clearly identifying the Stakeholders who hold the desirements is equivalent to identifying the market segment you are targeting.

So, what makes a good Stakeholders in Scrum? Those people who fit the above criteria and who can provide feedback that help the product evolve. Our big challenge is dealing with all of the other Stakeholders who don’t help or just become part of the noise. Good Teams need strong leadership, that can facilitate discussion and have a nose for good Catch Feedback[4] and Pull Feedback[5].

The classic definition of Stakeholders is that they are people with legitimate interests in the project. Stakeholders are people who should not be ignored; they are people who can have a negative impact on the Team if they are not attended to. Scrum Team Members are also stakeholders (with a lower case s) by the definition above but, the ones that we frequently struggle with are external to the Team.

Know who your Stakeholder is (and who it isn’t) and hone in what he or she really wants.

And, if you’d like help with building that Stakeholder relationship,
we’ve got coaching for that.

As Always. Stay Agile.

Notes and Sources

1-5 “Stakeholder.” “Product,” “Interested Bystander,” “Catch Feedback,” “Pull Feedback.” Accessed March 22, 2018. https://scrumdictionary.com.

The post What Makes A Good Stakeholder? appeared first on 3Back.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

So, let me talk about the easy stuff first. One of the best things that can happen to a Scrum Team[1] is that it finishes its work early in a Sprint[2]. It amazes me that Teams are confused about what to do, but they are. So here goes… If the Team finishes early, it seems to me there are two choices:

Take a holiday

Do something new

I have seen Teams take a half-day off if that’s all the time they have left, and I applaud this. In most cases, however, the Team should just bring something new into the Sprint and do it. By definition, the Items near the top of the Back Burner[3] are Ready Stories[4] that are no more than one short conversation away from being agreed to; that is, the Team needs a short conversation before it can start work on one of them.

So, the Team should work with its Product Owner[5] to figure out which Story on the Back Burner to do. Maybe it’s something the Product Owner wants, or maybe the Team gets to work on one of the Chores[6] (like some Refactoring[7] or something) that has been put off until later. It would be nice if it was a Story that the Team thinks might fit into the time remaining in the Sprint, so they find one, finalize the Doneness Agreement[8], task it out, and just do it.

Yes, it is really just that simple… unless the Team can’t find a Story that will fit in the time remaining in the Sprint. Then the Team can do one of two things: take a holiday, or just start a new Story, knowing that it will spill over into the next Sprint. In this second case the Story is actually part of the next Sprint, not this one.

Sometimes it really is just that simple.
And sometimes it isn’t.

For those times when it’s more complex,
we’ve got training for that.

As Always, Stay Agile.

Notes and Sources

1-8 “Scrum Team,” “Sprint,” “Back Burner,” “Ready Stories,” “Product Owner,” “Chores,” “Refactoring,” “Doneness Agreement.” Accessed March 1, 2018. https://scrumdictionary.com.

The post What Do You Do When You Finish a Sprint Early? appeared first on 3Back.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview