Loading...

Follow 3Back Scrum & Agility Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

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 3.0 White Paper and
a Scrum 3.0 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.

Read Full Article
Visit website
  • 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.

Read Full Article
Visit website
  • 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.

Read Full Article
Visit website
  • 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.

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

Let’s face it, you’re really busy. So, the idea of taking time out of your crazy work day to get a certification may make you ponder, “Is this really worth it? Will it help me do my job better?” If this is what comes to your mind about becoming a Certified ScrumMaster (CSM), don’t feel bad. Critically walking through the “why should I do this?” argument is time well spent. So is getting your ScrumMaster Certification. Here are some important reasons why.

1. You’ll get your work done better. Period.

Scrum enables Teams to perform at a higher level. (We’ve written an entire white paper on this subject.) Becoming a CSM means you and your Team will approach work differently. And, without getting into the nitty gritty of it (that’s what CSM training is for), this approach ensures dramatic improvements in:

  • Productivity
  • Return on Investment
  • Delivery of Releasable Software
  • Reductions in Product Failure
2. You’ll make more money.

Successful completion of a Certified ScrumMaster (CSM) class accrues Contact Hours or Professional Development Units (PDU’s) and is a recommended method to acquire or maintain the Project Management Institute’s (PMI) Project Management Professional (PMP)® ScrumMaster Certification also helps you achieve or maintain your PMI- Agile Certified Practitioner (ACP) credential. PMI-ACP recognizes a proven command of Agile principles, practices, tools and techniques, such as Scrum. According to the PMI Project Management Salary Survey – Tenth Edition[1], PMI certifications positively impact your marketability, leverage your credibility, and garner a higher salary. Plus, recent surveys show that CSMs earn a salary[2] compatible with Lead Developers.[3] This is welcome news, as it wasn’t always the case. Need we say more?

3. Your boss says so.

We know this isn’t your favorite reason. But, it’s a real reason. And, we bet there’s some smart thinking behind why your boss wants you to get your ScrumMaster Certification. Maybe your boss has his or her certification or is a Business Owner[4] or a Stakeholder[5] or a whole bunch of other Scrum roles that come with responsibilities that impact your job and would make a lot more sense to you if you were certified. (Meaning, you’d do your job better, which is what you wanted in the first place.) Or maybe your Team has some projects on the horizon where the contract requires ScrumMaster Certification. Or maybe your boss sees you as the type of inspirational Team Member that can help shape your Team’s performance through Scrum. Regardless of why your boss says so, run with it. Because we know you’ll reap the rewards.

Heard enough? Ready to become a Certified ScrumMaster?
We’ve got training for that.

As Always, Stay Agile.

Notes and Sources

1 “Earning Power Project Management Salary Survey 10th Edition.” Earning Power Project Management Salary Survey 10th Edition. January 22, 2018. Accessed February 12, 2018. http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/salary-survey-10th-edition.pdf?la=en.

2 Certified Scrummaster (CSM) Salary. Accessed February 20, 2018. https://www.payscale.com/research/US/Job=Certified_Scrummaster_(CSM)/Salary.

3 Lead Web Developer Salary. Accessed February 20, 2018. https://www.payscale.com/research/US/Job=Lead_Web_Developer/Salary.

4,5 “Stakeholder,” “Business Owner.” Accessed February 12, 2018. https://scrumdictionary.com.

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

Seasoned PO’s (Product Owners[1]) share a certain kinship bred from their time spent navigating the PO world; a world full of balancing, prioritizing and clarifying. We decided to capture their PO knowledge and ask them, “What do you know now that you wish you had known when you were a new PO?”

From this question came a glut of useful, real-world tips that we offer to you. We present to you, our top 10 tips to becoming a better PO.

1. Love your ScrumMaster

Remember your ScrumMaster’s primary responsibility is to help the team get better at doing what you, as PO, need them to do. Show your ScrumMaster the props he or she deserves, and it will come back to you in spades, helping you balance the PO role and the team’s work in a way you could not do on your own. Think of your ScrumMaster as your team’s sports medicine doctor, assessing the health of your team and prescribing just the right treatment to strengthen their muscles, build their endurance and train them to be a lean, mean high performing team.

2. Know your Stakeholders

A self-organized team grounded in Scrum has the ability to eliminate much of the political power play that is prevalent in the workplace. That being said, as a PO, politically and more importantly, productively, one of the smartest things you can do is to get close to your Stakeholders[2]. Understand their perspective. Be clear on their needs inside and out. You should be prioritizing the team’s work based on your Stakeholders’ desires, not on your assumptions of what they may or may not be thinking.

3. With great power comes great responsibility

There are many responsibilities that come with being PO. With that accountability[3] comes praise for  good results, but also blame for bad results. The fix? Be able, at all times, to justify your decisions in prioritizing the work. A sound justification for your team’s work prioritization is not only your safety net; it’s your 20/20 hindsight when things go south.

4. Don’t pull an Al Haig

After the 1981 assassination attempt on President Reagan, Secretary of State Alexander Haig famously announced in a press conference, “I’m in control here.” Technically, politically and legally that wasn’t actually the case. The same holds true for your role as PO with your respective team. You do not run the team. You are part of the team. You may make hard decisions and prioritize the work of others, but make no mistake. You are not in control here. Nor should you try to be.

5. Stop the micromanaging

You may think that your project will get done more quickly if you choreograph your team’s every step. But it won’t. Your team needs to stretch and reach and learn by doing. Your team needs to self-organize. And they will do this organically. But only if you take a step back and allow it to happen.

6. Don’t be a know-it-all

The reality is, your team knows more about their work than you do. Take the time to stop, listen and trust your team’s estimates. They get it more than you. They really do. The more you can lean into this trust, the more productive and fulfilling your PO-ing will be.

7. Never have a meeting to have a meeting

For every meeting you think you need to have, ask first, why am I having this meeting? What needs to get accomplished? And is a meeting the best way to accomplish it? If you determine a meeting is truly necessary, then remember the timebox is your friend. Not only should you always have an agenda, always have a timebox and stick to it. Your team will thank you for it.

8. Respect the sprint timebox

Speaking of time, that sprint timebox is there for a very good reason. It keeps everyone honest and provides critical retrospective and velocity data. Don’t artificially terminate or extend a sprint unless there is a major, compelling reason. What does compelling look like? It looks like the customer deciding they want to change the entire direction of the project. Compelling does not look like someone going on vacation.

9. Use all the Scrum tools in your Scrum toolbox

As PO, you’ve got a lot of tools at your disposal. There’s much more there than just the sprint board. You’ve got burnups[4], velocity tracking[5], storyotyping[6], etc. Each of these tools is designed to make your job easier. Don’t forget these tools make excellent information radiators, helping you to increase communication both within the team as well as to your outside stakeholders and management.

10. Clarify, clarify and clarify. Then, when you’re done, clarify some more

Sometimes taking the time to clarify may feel like an exercise in redundancy. It’s not. We can’t emphasize enough the importance of clarifying. Whether it be Stakeholder requests, ScrumMaster feedback or team expectations, things can get fuzzy pretty quickly. And fuzzy wastes time and productivity. If you can’t answer, “What does (fill in the blank with a fuzzy item) look like?” Then you need to clarify.

These seasoned PO’s had to learn these tips the hard way. But thanks to their struggles and successes, you don’t have to. Keep these tips in your back pocket and become a better PO.

Interested in furthering your PO understanding and implementation?
We’ve got training for that.

As always. Stay Agile.

Notes and Sources
1-6 “ Product Owner,” “Stakeholder,” “Accountability,” “BurnUps,” “Velocity Tracking,” “Storyotyping.” Accessed February 12, 2018. https://scrumdictionary.com.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
3Back Scrum & Agility Blog by The 3back Team - 4M ago

Once upon a time, there was a company. A large, multi-layered organization ordered with the task of developing and launching new software. And not just any software. Complex software, unlike anything the organization or the public at large had seen, or used, before. The new software carried with it a set-in-stone launch deadline. The pressure was immediately on to go live. And not just go live in one small testing site; rather, to roll out the software and go live everywhere at the same time.

So, the company did what it had always done. Being an organization not run by IT people, the company hired many, many outside consultants from many, many well-known places; each bringing his or her varied experience and unique work culture and expectations to the task at hand. The consultants put hundreds of developers on the project. Then, the company deployed the project using the common practice they always used, waterfall.

Don’t Go Chasing Waterfalls

Ahhh, waterfall. For those of you familiar with waterfall methodologies, you may just have groaned loudly, as you already see the writing on the wall for this project. For those of you thinking, “Waterfall? What’s the big deal? There’s a truck load of consultants getting paid big bucks to launch this thing. They’ll make sure waterfall gets the job done.”

To accurately set the scene, let’s revisit a few things we know about waterfall.

Waterfall:

  • Requires highly structured, highly regulated project organization.
  • Includes a detailed set of linear procedures and controls.
  • Is best suited for stable software projects where requirements are established and never change.
  • Necessitates that developers can predict problem areas and produce an accurate design before implementation.
  • Demands that each phase of development is fully complete before proceeding to the next phase.
  • Breaks down a project’s schedule so that approximately 40% of total time invested is spent on software conception and initiation and 40% spent on coding, leaving 20% for testing, implementation, and maintenance.

Now, let’s revisit a few things we know about this big project.

This big project:

  • Was completely and utterly new, unimplemented, and anything but predictably stable.
  • Was the definition of complex[1].

You can begin to see where this project was headed. Not surprisingly, the software was released and was, by all accounts, an epic fail.

Why the Epic Fail?

Little to No Testing
By the time all the conception, initiation and coding was completed, there was no time left allotted for verification[2] or validation[3]. The software was pushed out live, with only hours of testing under its belt.

Too many Cooks in the Kitchen
All those consultants meant one thing. Everyone had an opinion, but no one had ownership of the project; this problem is known as Flaccid Product Ownership[4]. Combine that with leadership that had no IT understanding, and you’ve got a recipe for disaster.

Project Sprawl
All those large teams of developers translated into a lot of unfocused work and unclear expectations. Some work was duplicated; some was missed entirely.

How Scrum Saved the Day

After the complete disaster, the company had an epiphany. Sure, the project was a total mess, but there still was a need for the software. The process needed fixing. And, to do that, it came down to the people. People over process. That’s the Scrum way.

The truckload of consultants and large teams of developers were sent packing. A very small and very focused Scrum Team came in to get the job done.

The Scrum Team used an incremental and iterative approach to:

  • Respond to changes in requirements as they arose.
  • Make changes as the project progressed.
  • Deliver[5] early and often.
  • Deploy the software in smaller circles; watch it, fix it and scale[6] it.
  • Have incredible success.

The project was saved. The software was deployed. And everyone lived happily ever after.

Think your company could use a little superhero help from Scrum?
We’ve got Scrum 3.0 for that.

As Always. Stay Agile.

Notes and Sources

1-6 “Complex,” “Validation,” “Verification,” “Flaccid Product Ownership,” “Deliver,” “Scale.”Accessed February 5, 2018. https://scrumdictionary.com.

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

Search Google Books on trust and candor and the first listings you’ll get are business examples. Why? Because for a Team to respond agilely, we need to be candid with each other and have a basic trust in each other. Naturally, we’ve all experienced being on a Team where this wasn’t the case, and our whole Team was held back as a result.

Being candid with each other means communicating and acting in a sincere, upright way: in other words, being open! Interestingly, the word candid has the same Latin root as the word candle: something that shines. So when we’re candid, we shine light in a direct, unfiltered way on what we see–we don’t “hide our light under a basket,”[1] as the saying goes. Candid communication drives agility because whatever my Teammate sees, he shares with me, so I see too, and together we’re able to respond and adapt.

If you think about the less-than-ideal Teams you’ve been on, you might be tempted to say, “Well, I would have spoken my mind but nobody did because we didn’t trust each other enough.” But is that really the way it works? Can we only afford to be candid once we’ve established trust on a Team?

Trust Is A Byproduct Of Being Candid

I’m going to argue that the opposite is true: trust isn’t a prerequisite, it’s a byproduct of taking the risk to be candid. And it’s a real risk: we may get shot down in a meeting, we may give it our all and still not be listened to. No risk, no growth, just more of the same!

To build trust by being candid, the Team should:

  • Write up working agreements
    The ScrumMaster or Team Leader[2] needs to help the Team write up its “social contract” about how we communicate with each other and work together. What are our ground rules? What do we expect from each other?
  • Hold everyone accountable
    Once we’ve got clear agreements, the ScrumMaster or Team leader needs to hold Team members accountable[3] for keeping them, prompting us when we slip, or revising what we’ve committed to.
  • Walk the talk
    The Team Leader must to model the behaviors he or she is advocating!
Take The Risk To Be Candid

Trust is built on a Team through repeated experiences of taking the risk to be candid with each other about what is or isn’t happening; what is or isn’t working. Not every risk to be open in a Team meeting will be successful, and for sure it won’t always be comfortable. But the only way to form a Team is to work through difficulties together–up until then, we’re just a collection of individuals.

As a Team takes risks, takes ownership of its shared agreements, and gains trust, their collaboration becomes more powerful, and the Team becomes able to respond to changing circumstances with greater Agility[4]. Until that Team spirit catches fire, the ScrumMaster or Team Leader is the trustee of the Team’s Agility; safeguarding the process and prompting, directing, coaching, and facilitating the Team toward greater collaboration.

Ready to take the risk to be candid
(and build Team trust)?
Learn how Scrum 3.0 can help get you there.

As Always. Stay Agile.

Notes and Sources

1 Farlex Dictionary of Idioms. S.v. “hide light under a bushel.” Retrieved February 1, 2018 from https://idioms.thefreedictionary.com/hide+light+under+a+bushel

2-4 “ScrumMaster or Team Leader,” “Accountable,” “Agility.” Accessed February 1, 2017. https://scrumdictionary.com/.

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

Every year as the middle of February approaches, our world is taken over by little red hearts, cherubic cupids hoisting arrows and foil wrapped drugstore chocolates. The heavily scented fragrance of Valentine’s Day is in the air. With the holiday right around the corner, for us at 3Back, our thoughts turn to partnerships that stand the test of time; a Scrummy yin and yang where complementary forces interact to create something great. We think we found it.

The Perfect Pair

In Scrum, there’s no better example of companion roles than that of the Product Owner[1] and ScrumMaster[2]. While these two roles are technically independent of one another, if one is not fully pulling their weight in the relationship, the other suffers. And so does the Team.

Great PO’s and SM’s each exhibit a specialized skill set that reflects their responsibilities. The PO focuses on the success of the Product. The SM focuses on the success of the Process. Great “SM/PO couples” speak the same language, understanding what to expect from each other and put in the effort to do their part.

It’s a Two-Way Street

What should the PO expect from the SM to cultivate their healthy relationship? The SM provides that critical facilitative piece of the Agile pie. As the Team’s advocate, the SM does whatever is needed to build a collaborative environment, remove impediments and encourage the Team to manage their work successfully. The SM provides support to the PO so that he or she can focus on what demands their attention, namely ensuring that the right product is made for the right customer at the right time.

On the other side of the coin, what should the SM expect from the PO? As the bridge to the outside world of Stakeholders[3] and Business Owners[4], the PO clearly communicates the big picture Product Vision[5] and business goals to the Team. With an eye on the Product Backlog[6], the PO provides prioritization and direction so that all that good Team collaboration nurtured by the SM can be put into action developing the product.

Finding Your Scrum Mate

Like any relationship, maintaining a healthy and strong partnership between the PO and SM is hard work. But we can help with those five little words, we’ve got training for that.

As Always, Stay Agile.

Notes and Sources

1-5 “Product Owner,” “ScrumMaster.” “Stakeholder,” “Business Owner,” “Product Vision.” Accessed February 1, 2018. https://scrumdictionary.com.

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

Even if you think that a “Fair Catch”[1] has something to do with a summer carnival fishing tournament and a “Flea Flicker”[2] can be eradicated with a dog collar, there are two things that all football and non-football fans know: The crazy intensity of the championship football season is among us. And, the only football teams that prove themselves worthy of achieving this level of greatness are the ones that are the epitome of a Well-Formed Team.[3]

Long ago, before Scrum was Scrum, a model of Team development was introduced to the world, setting the standard for understanding how Teams evolve. 50 years later, Tuckman’s model of Forming, Storming, Norming and Performing,[4] while not specific to the world of Agile, still holds strong. According to Tuckman’s theory, all Teams must proceed through a distinct order of stages to evolve to the ideal state of Performing, or as we call it, becoming a Well-Formed Team.

Forming

A short-lived phase; the Team gets acquainted, learns roles and responsibilities.

Storming

A challenging period; as the Team experiences disagreements, power struggles and conflict emerge.

Norming

The Team discovers the light at the end of the tunnel, establishing guidelines and understanding process.

Performing

The Team gets it; collaborating, anticipating and adjusting. Work is efficient, and the Team is motivated.

In football, it’s easy to see what a Well-Formed Team looks like. While they may start out the pre-season Forming, by the time division playoffs are happening, they are rock solid Performing. Every member knows their role in the Team. They work as a whole. They anticipate, inspect, adapt and work hard toward a common goal. Barring injury, the Team remains intact as a unit; well versed in what to do, why to do it and when to do it. The result? They win the game.

Sure, we’ve been talking football this whole time. But, you knew we’d bring up Scrum soon. There’s no reason a Scrum Team can’t function the same way as those giants of the gridiron. Scrum Teams need the time to evolve through Tuckman’s stages to achieve greatness. That’s why we are always surprised when some organizations choose to disband and reform Scrum Teams with every project, effectively eliminating the Team’s ability to evolve. Unless there’s an overwhelming extenuating circumstance, we maintain that Scrum Teams should stay intact. Otherwise, they’ll never make it to the Championship.

Tired of hearing from Monday Morning Quarterbacks in your organization? Ready to improve your Team’s Agility? We’ve got coaching for that.

And, if you’d like to dig deeper into what it takes to become a Well-Formed Team,
we’ve got a white paper for that too.

As Always. Stay Agile.

Notes and Sources

1 In case you were wondering, a Fair Catch is a signal the kick returner gives by waving his arms. When this happens, the opposing Team is required to allow an uninterrupted opportunity to the returner to field the football.

2 A Flea Flicker is a trick play by the offense that involves the running back throwing a pass backward to the quarterback, followed by the quarterback throwing a forward pass to a receiver.

3 “Well-Formed Team.” Accessed January 25, 2018. https://scrumdictionary.com.

4 Developmental sequence in small groups. Tuckman, Bruce W.Psychological Bulletin, Vol 63(6), Jun 1965, 384-399. http://dx.doi.org/10.1037/h0022100.

Read Full Article
Visit website

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