“The team just doesn’t have a sense of urgency.”
Have you ever uttered those words? Or felt the frustration from this preconceived notion? Have you ever wondered why your teams aren’t performing to your expectations? You question whether they just lack passion or simply don’t care? Or maybe they just aren’t into their jobs? Are team members just phoning it in?
Did it ever occur to you that…
Maybe they don’t have the skills necessary to perform the work, and need to be taught? Or maybe they can’t focus due to getting pulled in multiple, conflicting directions? Maybe the user stories are too large, too complex, or too bulky to finish within a sprint? Maybe they are working on outdated laptops, with severe performance issues, and they literally cannot speed up their process? Maybe they don’t understand the expectations due to language, cultural, time zone, or physical barriers? Or perhaps, maybe the sense of urgency was never adequately conveyed because they don’t know why they’re doing the work?
How would asking curiosity-based questions change our internal narrative? The dynamics of our relationships? What if we proceeded based on curiosity, rather than secretly fuming from a place of scrutiny and distrust?
Assuming positive intent (API) is the first step towards strengthening our bonds with our teams, rather than destroying them, based on false presumptions.
I challenge you to try API as your personal internal experiment. Afterwards, reflect on your experience: Did your relationships shift? Did you gain insight about yourself, your team members, or the process? Did you find yourself responding from a place of empathy or concern? How did it feel to assume positive intent – did you feel less frustrated and gain empathy?
This is just one step we can take to strengthen our relationships and build in psychological safety. Not only at work, but in our personal lives as well.
Stay positive! Stay curious!
During a recent client engagement, I advocated that Scrum Masters schedule one-on-ones with their team members. Afterwards I was approached by a Scrum Master who was curious as to the “why” behind this recommendation. He thought the purpose was to receive feedback and answer questions regarding the Scrum Process. His assumptions were correct, but he only touched the surface, so I thought I’d dive a little deeper.
The Scrum Master is a servant-leader for the Scrum team. They serve the development team in self-organization and cross-functionality – through training, mentoring and coaching. Great Scrum Masters want to help grow the team, enforce accountability and encourage productivity, and empower collaboration.
Essentially, the Scrum Master is the team coach.
A One-on-One session is an extremely efficient technique to:
One final note – spending one-on-one time with a person sends the message that the person is valuable. When the focus is on understanding team members’ concerns and helping them be productive, the SM is also building trust…. Which is KEY for high performance.
The technique is not only useful for team members. I often recommend that Scrum Masters schedule regular one-on-ones with the managers of their team members. This is NOT a complaint session nor focused on airing dirty laundry.
Instead, you establish a partnership where you both are helping each team member, and the overall team, be the best they can be. This also helps the manager increase the effectiveness of their own one-on-ones with team members.
I’ve noticed the term “Scrum Master” results in a variety of facial expressions for people who are unfamiliar with the Scrum roles. These run the gamut from confusion to suspicion to outright incredulity.
“What does this even mean? What is this “Master of Scrum”?
Sounds like complete rubbish; an imaginary role that offers no credibility or substance.” Their body language further reinforces their intrinsic cynicism – arms crossed, neck tensed, palms clammy. I imagine they envision hundred-dollar bills engulfed in flames, each time a Scrum Master deposits their paycheck.
I rise to the challenge and dutifully describe the role of the Scrum Master.
A Scrum Master is the “servant leader” for the Scrum Team, Product Owner and organization. This means promoting and supporting Scrum through teaching Values, theory, practices, and rules. Scrum Masters serve the Scrum team by shielding them from outside forces, removing impediments and coaching them in self-organization and cross-functionality, all of which allow them to focus on creating high value products. They also encourage the team to improve its development process and practices to make it more effective and enjoyable for the next sprint.
They serve the Product Owner by offering techniques for effective product backlog management, ensuring goals, scope, and product domain are understood by everyone, and facilitating Scrum events as requested or needed. The organization relies on the Scrum Master to lead and coach the Scrum adoption, induce change to increase the productivity of the Scrum teams and help everyone to understand and enact Scrum and empirical product development. In addition, the Scrum Masters are continually monitoring transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
Without Scrum Masters, we must assume that the Scrum Team and a Product Owner work together like a well-oiled machine and fully comprehend Scrum. (I have yet to experience this.) Who is going to help those outside the team understand which interactions are helpful and which aren’t? Who will explain the agile “Why” behind the agile “What”? Who is monitoring the health of the team, keeping Scrum events focused & efficient, and coaching the team on autonomy, cross-functionality, and self-organization? Who is continually observing the team dynamics, enforcing the agile mindset, and challenging for continual improvement?
After explaining all of this, a mental light bulb turns on, I know this because their facial expressions change. Their eyebrows relax, body leans forward, fingers steepled at their lips, in a thought-provoking manner.
AHA! Perhaps I’ve cracked the code.
What if we replace the role of “Scrum Master” to “Team Coach”? If leadership and team members viewed them as “Team Coaches”, then perhaps they wouldn’t be continually trying to understand or justify their role.
After all, every great team needs a coach. Don’t they?
In the eleven years I’ve known my husband, I gained 30 pounds. I’ve tried numerous attempts at losing the weight – I’ve counted points. I’ve counted calories. I tried low fat diets, no fat diets, low carb diets, no carb diets. I would lose 5 or 10 pounds, and then gain it back. It was a wild roller coaster and I felt like a failure… and I was frustrated. Convinced something was wrong with my body, I asked my doctor to perform multiple blood tests. They always came back fine; I was quite healthy. Overweight, but healthy. I was convinced that it was the DIET’S FAULT.
This was weighing heavily (pun intended) on my mind while creating a training deck. I was in the process of inserting a slide on the 5 Core Scrum Values, when it hit me: I wasn’t personally aligned with these values myself.
I wasn’t focused. Like most people, my diets kicked off on a Monday morning. I followed the diet to a “T” on Mondays and Tuesdays. Wednesday’s were a little slippery, sometimes I would sneak a free office cookie or two. Thursday’s were “girl’s night out” which meant indulgence. Fridays: Date night with my husband which meant more indulgence.
By Saturday morning, I would wake feeling remorseful and defeated. I would then chalk it up to a “bad week” and decide to start again the following Monday, giving myself the weekend to “just relax and enjoy” – which really meant, fried food, wine and exercise avoidance.
I wasn’t being open or honest with myself. I continuously made careless choices without any sort of personal accountability. I literally ignored my role in this thing called weight loss. It was the epitome of denial.
I wasn’t respecting the rules of any of the diet plans. I cut corners as much as possible – over measuring, under exercising, sneaking bites of this or that. Essentially, I was a big fat cheater.
I didn’t have the courage to admit this to myself. It was all too easy to blame everything around me but being honest was scary. I felt vulnerable and embarrassed. Weak and shameful.
Clearly, I wasn’t committed to losing this weight. All signs point to this.
I realized it wasn’t the diet’s fault.
It was mine.
What’s my point here? If Scrum isn’t working for you, I challenge you to turn inward and ask yourself if your organization is aligned with the 5 Scrum Values.
Are you FOCUSED?
Are your team members adhering to WIP limits? Do they have WIP limits? Are your scrum teams able to work on what they committed to at planning, or are they continually switching gears? How’s your quality? Do you have test automation? Is your Scrum Master focused on process improvement? Do you even have a dedicated SM?
Are you OPEN?
Is all the work visible on the Scrum board (or are your team members working on “side” projects no one knows about)? Do your teams follow working agreements? What about Definition of Done or Definition of Ready? Do your teams feel comfortable raising concerns or are they “yes” people?
Are you RESPECTFUL?
Are you following the Scrum Guide? The 12 Principles? Does your organization respect your team’s working hours or are they expected to work nights / weekends to meet unrealistic deadlines? Are your team members “T” shaped? Cross functional? Do developers help test? Does the team feel responsible for the work, or do they still have that “silo’d” mindset?
Are you COURAGEOUS?
Do you have the courage to approach the difficult conversations, the elephant in the room? Are your teams encouraged to experiment? Do they have the organization’s support if they fail? Are your Product Owners empowered to make decisions or are they just order takers? Does your company ever say “no” to clients or at the very least, negotiate scope? Do your team members ask for what they need?
Are you COMMITTED?
Are your team members committed to the sprint goal? How often are they rolling stories from sprint to sprint? What are the consequences when this happens? Is the entire organization committed to continuous improvement (top down and bottom up)?
My final point here:
It’s not Scrum’s fault.
Just like it wasn’t the diet’s faults.
If Scrum isn’t working for you, I challenge you to turn inwards and ask yourself if you are aligned to the 5 Scrum Values. Think FORCC (Focus, Openness, Respect, Courage, Commitment).
Today I placed an online lunch order to be picked up at noon. I’ve eaten at this establishment on numerous occasions and have always ordered the same thing: Zoodles (zucchini noodles) and eggplant meatballs. This is my “go to” meal when I want something that tastes decadent but is low in calories.
It’s a beautiful, sunny spring day and I enjoyed my walk to the restaurant. I wandered up to the counter, gave my name, received my bag and headed home. On arrival, I pulled the container from the packaging and snapped off the plastic lid.
I was greeted with large zucchini chunks, not zoodles. I expected zoodles. Where were my zoodles? Why wasn’t I told there would be no zoodles? The receipt reads “Spaghetti and meatballs”. I check the website and re-read the description just to validate that I haven’t lost my mind. Yes, it says zoodles. First world problems I know, but I was incredibly disappointed to have received zucchini chunks instead.
I PAID FOR ZOODLES, damnit!!
What does this have to do with agile?, you may be asking yourself.
I’ll tell you.
There’s a certain mindset in agile, a culture of transparency, honesty, courage, rigor. If the zoodle-makers (“zoodlers”) had an agile mindset, someone would have either A.) called me prior to making the dish to inform me that zoodles were not happening for whatever reason or B.) told me upon arrival, with an apology, explanation and a potential discount and/or food swap.
When I contemplate what agile “means to me” – I inevitably return to the 5 scrum values: Focus, Openness, Respect, Commitment and Courage. It’s about telling the truth. It’s about humility and vulnerability and doing what’s right, not what's easy. It’s about navigating the complex world with grace, poise, and love… it’s self respect and consideration for others. Agile is grit, truth, passion. Righting the wrongs. Shining a light on the elephants. Being courageous, living your truth.
The agile mindset does not discriminate. Whatever your career path, whatever your role – whether you are a software engineer or a zoodler, we should all aim to be focused, open, respectful, committed and courageous. That’s the agile way.
I recently attended a talk given by a colleague known for her sense of humor and creativity. While her audience was sprinkling in, the speaker opened her browser and navigated to Wheel Decide; which is a customizable virtual wheel of fortune, complete with the spin and clicks (but minus Vanna White & Pat Sajak).
As an ice breaker technique, she had pre-populated her wheel with engaging & open ended questions for the audience. As folks settled in, she asked for volunteers and spun the wheel. They were then presented with a question determined by the .. wheel of course.
This approach towards relationship building resonated with the group (which consisted of company wide ScrumMasters & colleagues). Their interactions between the questions and each other was light hearted and humorous.
Back at my desk, I created my own Wheel of Fortune, complete with questions such as:
(In full disclosure, these questions were shamelessly borrowed from this book.)
I now open my "getting to know you" wheel at the start of the standup. The team randomly chooses the lucky recipient and the wheel is spun. This is a simple way to begin our day and it typically leads to smiles and entertaining stories.
I consider myself an outgoing introvert - definitely reserved among a large group of unfamiliar faces, but genuinely engaged & energized when it's one-on-one.
In my spare time, I gravitate towards jigsaw puzzles, reading, coloring, crafts, meditation and yoga. My energy tends to soar after brief periods of solace and silence, my mind woken and brain invigorated. Following this recharge, I've reached the pinnacle of my social self - the Kim who wants to peel back the inner layers of my colleagues / friends / family members ... strengthen relationships.. form tighter bonds... become BFFs....
Sometime this enthusiasm isn't shared, as I've encountered a sprinkling of withdrawn / quiet / "leave me alone" types during my IT years, And I get it.
I really do.
However, as a Scrum Master, I am compelled to build relationships and strengthen bonds, but I'm also sensitive to the fact that this goal may not be reciprocated. Which I find, to be a tragedy, really.
To nudge people into opening up, I've created a sampling of powerful questions (shamelessly stolen from my own coaches) - which seems to do the trick. I keep these questions posted on my monitor and return to them when/if conversation stalls.
Here they are:
Internal to work
Outside of the office
A few tips:
* Never ask a question you don't feel comfortable answering yourself.
* Use these questions sparingly! The intent is not to ambush or interrogate our colleagues.
* Consider your audience - if you feel the question may not be taken well, don't ask it! Employ common sense, empathy and respect.
I hope this helps! Do you have additional questions I can add to my list? Let me know!
What is Sprint Planning?
Spring planning is needed for the team to negotiate which stories will be tackled within the sprint. This should be decided after reviewing the number of hours available against the number of task hours required. In addition to hours available, the team should understand their velocity/trends as well - but that's another blog altogether.
How is it done?
1. The Product Owner prioritizes the refined sprint backlog stories and clarifies requirements.
2. The team’s “Sprint Budget” is identified – this is the number of available hours the team has to work on during the sprint. Ideally, the dev team is allocated to working 6 hours per day, to account for meetings and other interruptions.
In my Deutsche Bank days, the team would write their names on the whiteboard (stacked, as rows) and the days of the sprint (as columns). Looking at the days, they would write a "6" within their row for all days they would be working at 100% capacity. If there were holidays, PTO, offsite training - those days would be shown as "0". We would count the number of all teammember hours available and notate that as well.
3. Stories are deconstructed into tasks.
As a Product Owner for this group, I taped & prioritized the printed stories / wireframes / gherkins etc. to the whiteboard. Before tasking began, I would review the stories one last time and answer any questions. From there, they would self organize into small groups and tackle the tasking for each of the stories.
4. Tasks are estimated in hours.
6. Add up task hours and deduct them from the Sprint Budget.
7. Commit to the stories the team knows they can get done.
8. Identify several stretch stories just in case the team delivers early.
My DB team was cross functional and "T" shaped. The developers were able to assist with testing as needed, which allowed them to truly own & swarm on work. During the tasking part of this meeting, the Product Owner is not involved although she should be available for any questions that arise. Typically, the ScrumMaster facilitates this session with the team members.
The end result of this session is for the team to:
Benefits of Tasking:
Challenges of Tasking:
As Scrum Masters, we are responsible for having the courage (<-- One of the scrum values) to not only observe, but to also provide tangible, constructive and valuable feedback to our team members as well.
Even if it’s uncomfortable / awkward / scary.
I grew up an only child and was thrilled when praised by my parents, teachers, friends, family etc. Accolades in the form of hugs, paper certificates, applause, shiny gold star stickers or smiles confirmed my value and motivated me to maintain or improve my good work.
As a professional adult, I still bask in the warmth of positive recognition and compliments, but know it’s not always sunshine and daisies. I can recall a conversation with a previous manager/mentor who once asked how I like to receive feedback. I smiled. “Are you familiar with the shit sandwich?”.
The “Shit Sandwich” is built like this: Bread (flattering content) + Meat (unflattering content) + Bread (More flattering content).
Because I’m an extremely sensitive perfectionist and I absolutely hate to disappoint, I respond well to this structure. Although I’d love a delicious glutinous carb only toasted sandwich, I welcome observations and suggestions for further improvement.
My second favorite feedback tool is the SBI, which stands for “Situation, Behavior, Impact”.
According to The Center for Creative Leadership, “When you structure feedback in this way, your people will understand precisely what you are commenting on and why. And when you outline the impact of their behavior on others, you're giving them the chance to reflect on their actions and think about what they need to change. The tool also helps you to avoid making assumptions that could upset the other person and damage your relationship with him or her.”
Here’s a real world example:
During our retrospective yesterday (situation), you were texting on your phone when the other team members were adding sticky notes to the board (behavior). You are highly regarded on this team so when you appear checked out, I’m concerned that other team members will also follow suit. (impact).
For me, the SBI method is easy to apply and helps to provide behavior changes. Also, it allows me to completely consider the what, why and how prior to the conversation.
To find out how they would like their feedback to be given, provide a few options to your team members. By opening the conversation this way, you’ll have a much more engaging and effective discussion.
The purpose of a retrospective is to inspect how the previous sprint went with regards to people, relationships, processes and tools. This is where we reflect on ourselves and our work in order to identify the good, the bad and future opportunities.
Retrospectives allow us to create an actionable plan to implement improvements so that we can become better at what we do. After all, the bad habits we have developed over the years are not going to disappear with the wave of a magical wand & a "bippity bippity bop!". Teams have to continually work to reinforce good patterns of behavior and eliminate the not so good.
1.) Hold a retrospective at the end of every sprint. (Very Important.)
Basic Rules of Engagement:
TIPS FROM OTHER SCRUMMASTERS: