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.
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.
In Modern Scrum, we define an impediment as anything that causes the Team to not be at its best. That’s an intentionally broad definition because impediments come in all shapes and sizes. Sometimes, impediments look like fears, sometimes they look like risks and sometimes they look like problems. Regardless what shape they take, we all know the negative effect impediments can have on the Team.
Enter the ScrumMaster.The ScrumMaster has a lot on his or her plate, with one of the primary responsibilities being to facilitate the removal or reduction of impediments. Unfortunately, there is no magic wand for impediments. The reality is, some impediments can be eradicated. But, others can’t be. Usually, though, they can be diminished in a way the Team can deal with them in a productive manner. To this end, we’ve polled some of our favorite ScrumMasters and come up with our Top 5 Ways To Kick Impediments To The Curb.
1. Stand It Up
The Daily Stand Up is an integral part of a well-formed Team, offering an allotted and preserved time for increasing communication and visibility. The Scrummiest of ScrumMasters knows this is the ideal time to outright ask the Team if there is anything standing in their way, literally getting it straight from the Scrum horses’ mouths. Armed with Team feedback, the ScrumMaster is off to the races to research, remove or at least reduce any impediments.
2. Don’t Be Afraid to Get in a Fight
The ScrumMaster is part facilitator, part influencer, part guru and part Mama Bear. The Mama Bear role means it’s up to the ScrumMaster to protect the Team by acting as a filter to the outside world and guarding the Team against distractions. Any Mama Bear ScrumMaster will also say this means owning the health and wellbeing of the Team as priority one. Sometimes that means going neck and neck with the bigwigs to do what’s right for the Team. Never second guess that Mama Bear instinct. And never be afraid to stand up for the Team to the Business Owners and Stakeholders.
9 out of 10 ScrumMasters (and some dentists) agree a Team that uses Information Radiators simply works better. Meaning: keeping information visible, such as a Scrum Board, a BuildUp Chart or an Open Impediments List, helps the Team in numerous ways. Take the Open Impediments List, for example. For one, it keeps everyone on the same page. For two, it makes sure impediments don’t fall through the cracks and morph into really big issues. For three, it feeds Team morale. How? When the Team sees their impediments listed, it reinforces that they are being heard, and that’s one of the intangibles that make the difference between a good Scrum Team and a great Scrum Team.
5. Be Present and Connected with the Team
If every ScrumMaster would take a moment to be more present; to observe and to engage, to listen, and most importantly, well, to shut up, Scrum Teams would live in a world with fewer impediments. A truly connected ScrumMaster encourages the Team to hold each other accountable, to challenge and, in turn, grow. A smart ScrumMaster will enable the Team to celebrate each other’s success, take the time for the Team to play together, and, just like a good kindergarten teacher, allow friendships to blossom. Simply put, if every ScrumMaster would listen more and talk less, Teams might find that impediments seem to melt away under their watchful eye.
So, ScrumMasters, pull on those Scrummy boots of yours. Take this Top 5 and start kicking those impediments to the curb.
Throughout our day, we experience an inordinate amount of noise. Whether it’s the garbage truck barreling down our road at 5 am, the dog that excitedly greets every passerby or the co-worker’s emphatic phone conversations on the other side of the paper-thin cubicle wall, noise is everywhere. While some noise may be enjoyable, like a baby’s giggle or the Keurig doling out that first cup of coffee, most noise is just that, noise. And it’s annoying.
We all know that Stakeholder who feels like the rules don’t apply to him or her. They’re the ones who invite themselves into the Team Member’s work area to discuss concerns or drop in uninvited to Dev Team meetings. While plastering a “Keep Out” sign may truly express how the Team is feeling, it’s probably not the best tactic. What’s a better one? Tag team the ScrumMaster and PO. Let the ScrumMaster play the role of Mama Bear by protecting the Team and redirecting the Stakeholder to take their ideas and concerns to the PO instead. The PO, in turn, makes sure the Stakeholder’s needs are being met on their turf, not the Team’s. Without that outside interference, the Team is more united in effort and better equipped to focus on the task at hand. And get it done.
2. Fight the Good Fight.
By the good fight, we mean fighting to make sure the Team focuses on one thing at a time and is not pulled in all directions. While many Team Members may want to throw their hats in the ring for this fight, the PO needs to don the boxing gloves and make this happen. It’s on the PO to prioritize and force-rank the work for the Team so that only one item can genuinely be number one. This may mean the PO must lead some difficult conversations and negotiations with Stakeholders and Business Owners, but for high-quality work to occur, a singular focus is non-negotiable.
3. Find Your Team’s Rhythm. And Stick to it.
Scrum is all about rhythm, exploring and establishing repeatable patterns that lead toward high-quality outcomes. One of the quickest ways to increase noise within your Organization is for the Team to lose their rhythm. Lack of Team rhythm breeds distraction and ineffectiveness. Take, for example, an inconsistent Daily Standup ritual. If Daily Standups have variable meeting times and length, unpredictable attendance or are skipped entirely, the Team will lose their rhythm. Without that regular check-in to inspect and adapt, that pesky organizational noise creeps in, causing the Team’s focus to go rapidly down the drain. It’s up to the ScrumMaster to help the Team find their rhythm and make sure the beat is strong enough that it becomes second nature.
4. Seeing is Believing.
A good ScrumMaster spends time organizing the noise that is heard by the Team. A great ScrumMaster spends time making sure the Team only hears what they need to hear at the right time. Increasing the methods of Team communication masterfully aids this endeavor. A well-placed Information Radiator, one that is large, easily visible, understood at a glance and kept up to date, means readers see the information they care about without having to ask anyone a question. This translates more communication with fewer interruptions. And less noise. Not to mention a heightened motivation as Team Members actually see progress towards a goal. Seeing truly is believing.
5. Remember the “Art of the Possible.”
Sometimes in Scrum, we need to return to our roots to reduce noise. A fundamental principle of Scrum is “the art of the possible;” guiding Teams to think about what can be done, not what can’t. Rather than succumbing to the noise surrounding the problem and what can’t be done, the Team’s energy would be better exerted toward solving the problem with the available resources and what can be done. The result is a Team that is better equipped to produce something that is good enough and moves on instead of being driven into complete paralysis by a quest for perfection.
Did you hear that? It sounds like we’ve got a quiet Organization in our midst.
The ScrumMaster is seldom a ‘Master of Scrum;’ but the ScrumMaster’s primary responsibility is to help the Scrum Team use and improve its use of Scrum. This isn’t simply for Scrum’s sake; it’s because the Team needs to get better at doing what the Product Owner needs it to do. In practice this means that the ScrumMaster works with the other Team Members to help the Team produce Quality Results at a rapid, though Sustainable Pace.
The ScrumMaster is a leadership role that is unique to Scrum. Even though it’s a leadership role, it comes with no management power. In this sense, the ScrumMaster is frequently referred to as a “servant leader,” leading by example without management authority. Any authority that the ScrumMaster has is a moral authority that is granted to the ScrumMaster by the Team.
The ScrumMaster uses this moral authority to help the Team improve its internal processes; to help the Team become more cross-functional, self-organized, self-managed, and self-aware; and the ScrumMaster works with the Organization and the Team to manage the impediments and constraints that are affecting the Team.
Not only that, but there are many essential roles to the ScrumMaster. Each of these essential roles is familiar to us, but the combination of them is special.
The 7 Roles
The ScrumMaster is constantly working with the Team, helping it get better. The ScrumMaster facilitates many of the Scrum Ceremonies or Events. Additionally, the ScrumMaster facilitates the Team’s self-organization, ensuring the Team follows the Scrum process.
The ScrumMaster mentors the Team as to what Scrum is and how to use it. The ScrumMaster may also help Team Members improve their technical abilities in whatever way he or she can.
The ScrumMaster acts as a referee in escalated internal disputes and external disputes that heavily impact the Team. This is a special case of the Facilitator role but is common enough that it needs to be called out separately.
The ScrumMaster acts as the conscience of the Team, especially when it comes to the Team Values. When a Team Member (or the Team as a whole) is not living the Values, it is the ScrumMaster’s job to make this fact visible and try to do something about it.
The ScrumMaster acts as the ‘canary in the coal mine’ when it comes to process. That is, if things aren’t going as they should, the ScrumMaster should be the first to notice the ‘process smell’ and bring it to the Team’s attention, helping to remove whatever impediments necessary to resolve it.
6. Impediment Manager
One of the ScrumMaster’s primary responsibilities is to manage the impediments or constraints that are getting in the way of the Scrum Framework or keeping the Team from reaching their full potential of producing a quality product. Sometimes the ScrumMaster does this by empowering and encouraging the Team to manage its own impediments and constraints, but more often the ScrumMaster must work with the Product Owner, Business Owner, or others in the Organization to help resolve these impediments.
The ScrumMaster brings his or her skills to the Team. Often, the ScrumMaster understands how the Organization works and acts as a bridge to help the Team adapt to the Organization and help the Organization adapt to the Team. Often this bridge work is in tandem with the Product Owner.
Whatever It Takes
A great ScrumMaster juggles these seven essential roles and does ‘whatever it takes’ to help the Team get better so that the Team can do the work the Product Owner requires. Because of this ‘whatever it takes’ attitude, the ScrumMaster often needs to take the cultures of the Team and the Organization into account. There is no ‘one size fits all’ answer to specific situations that may arise for the ScrumMaster – it is all situationally dependent. Not all ScrumMasters are appropriate for all Teams, and ScrumMasters must constantly be self-evaluating to determine if they are effective. If they are not, they owe it to their Teams to refine their skills and work toward a path of improvement.
Starting. It’s on all of our minds as we work through the first week of the new year. The concept of starting brings to mind one of the most frequently asked questions I receive when I am both training and coaching. When should you start a Sprint? And, the question’s inevitable counterpart, when should you finish a Sprint? The answers I give are consistent. I encourage Organizations and Teams to follow the Lean Principle of building-in quality; that is, make everything as unlikely to break as possible. When it comes to Sprint boundaries, regardless of the length of the Sprints, the least likely candidates are starting on Mondays and ending on Fridays.
Why Shouldn’t You Start a Sprint on a Monday and End on a Friday?
There are several reasons why Monday-Friday Sprint boundaries are suboptimal. In the United States, at least, most holidays fall on Mondays, almost certainly assuring disruption of Sprint Planning at least a few times every year. And while ending Sprints on Fridays might seem to offer the prospect of a nice break in between Sprints, the all-too-common refrain from the Team at the Sprint Review is: “Oh yeah, we’re done with everything, but we just have a little testing/coding/cleanup, etc., to finish over the weekend.” Uh-oh.
The Mid-Week Fix
Fortunately, there is an extremely simple method of fixing these (and many other) common problems resulting from Monday-Friday Sprint boundaries: start and finish in the middle of the week. I personally like starting fresh with Sprint Planning on Wednesday mornings and wrapping up with the Sprint Review and Retrospective on Tuesday afternoons. Using this Sprint boundary template immediately remedies the Monday-holiday disruption. Finishing the Sprint on Tuesday afternoon — with the Retrospective as the last thing the Team does, always, without fail — very neatly eliminates “we’re done, but we’ll finish over the weekend” syndrome as well.
Another benefit of the Wednesday-Tuesday Sprint cycle is that it supports adherence to an oft-violated Agile principle: sustainable pace. As a coach, I am not about to encourage or even allow teams to get into the habit of working weekends between Sprints. The most effective way I have discovered to deal with this problem is simply to make it impossible: there is no weekend or other exploitable time between Sprints.
Closing out each Sprint on Tuesday with the Retrospective provides the Team with the full experience of accomplishment and closure, of finishing the work of one Sprint before moving on to the next. Indeed, I invariably find that Teams are anxious to get started on the next Sprint and welcome the opportunity to start fresh the very next morning
“We had a few good Retrospectives, but they stopped working;” “I don’t know what the point of this is anymore;” “Maybe this Retro thing was a good idea once, but we need to try something else.” “Can we just finish this so we can get back to work?”
These are the kinds of things we say when a repeating process like Team Retrospectives, that used to work or maybe seemed to work once, has stopped feeling useful. In a moment like that, the process itself (the Retro) feels like the problem, or at least it’s not helping—it’s taking us away from “getting our real work done.”
The Retro has shifted from being a good habit to a bad routine.
What’s going on here? Philosophy and psychology tell us that we can intuitively recognize when a process like a retro is working, even if we can’t always tell why it’s working. On the other hand when a process isn’t working, we’re sometimes tempted to throw the baby out with the bathwater, dump the process or at least minimize our investment in it in order to get back to “the real work.”
Human beings are complex creatures—it’s not just important that we do something but why we do it. When we lose touch with “why” we’re doing something like a Retro and focus only on the fact that we did it, we’ve reduced a process that’s supposed to make us smarter and more effective to a routine—a box to be checked.
Naturally none of us literally forgets what the Retro is for! But when the Retro becomes just a required routine, we begin to act as if we’ve forgotten its original purpose. Recovering and reawakening our original sense of purpose can be uncomfortable because it means interrupting what we’re doing, stopping, and asking “why?” questions: Why are we doing this? Why are we feeling disengaged, frustrated, as if we’re wasting valuable time? Why was the retro supposed to be helpful in the first place?
Practical questions to help get a Retro back on track can include:
What’s our most important objective in this meeting?
What nagging issue haven’t we addressed yet?
Why are we feeling disengaged?
How has this meeting stopped feeling useful?
We may look to the ScrumMaster to be guardian of our Retro process, but in reality it’s up to each of us to raise our hand if things get stuck, risk a little discomfort, and ask the question: “Can we talk about why we’re doing this?”
Charles S. Peirce, founder of the philosophy of Pragmatism, wrote that when our “habits of mind” no longer seem to work, we feel doubt, which leads us to actively inquire by asking key questions.
William James, founder of American psychology, wrote that habit tends to “diminish the conscious attention with which our acts are performed,” meaning that we need to wake up periodically to why we’re doing what we’re doing, or else even good habits can become empty routines.