We are experts in Agile Theory.Our training transforms the fundamentals of Agile Theory into practical implementation. By exploring real world, client-driven experiences, we give you the right Agile tools and techniques to use with your team. Follow this blog to know about Agile and scrum in depth.
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.”
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.
Help the Team Members understand, implement, and improve their use of Scrum and Agility; and
Help the Team identify its Kaizen every Sprint.
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 (with expertise in organizational behavior), and is considered the ‘senior Scrum Master’ in the Organization.
When An Organization Scales, There Are 4 Main Forces In Play:
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)
The need to communicate across Teams to Cooperate, Coordinate, and Collaborate
The need to centralize common functions and features to leverage economy of scale and become more efficient
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.
Stakeholders are the reason we develop Product 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. 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 and Pull Feedback.
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.
So, let me talk about the easy stuff first. One of the best things that can happen to a Scrum Team is that it finishes its work early in a Sprint. 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:
So, the Team should work with its Product Owner 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 (like some Refactoring 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, 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.
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:
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 or a Stakeholder 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.
Seasoned PO’s (Product Owners) 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. 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 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.
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, velocity tracking, storyotyping, 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.
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.
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.
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 or validation. 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. Combine that with leadership that had no IT understanding, and you’ve got a recipe for disaster.
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:
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,” 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!
Hold everyone accountable
Once we’ve got clear agreements, the ScrumMaster or Team leader needs to hold Team members accountable 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. 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.
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 and ScrumMaster. 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.
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 and Business Owners, the PO clearly communicates the big picture Product Vision and business goals to the Team. With an eye on the Product Backlog, 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.
Even if you think that a “Fair Catch” has something to do with a summer carnival fishing tournament and a “Flea Flicker” 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.
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, 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.
A short-lived phase; the Team gets acquainted, learns roles and responsibilities.
A challenging period; as the Team experiences disagreements, power struggles and conflict emerge.
The Team discovers the light at the end of the tunnel, establishing guidelines and understanding process.
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.
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.