Scrum Values II: Today’s Episode — Courage.

Courage is an easy thing to understand.  It’s also incredibly hard for people to fully embrace when we are dealing with the Scrum Values.  As before, I want to start by looking at the one sentence in the Scrum Guide that applies:

“The Scrum Team members have courage to do the right thing and work on tough problems.”

There is it in a nutshell.  Do the right thing, and work on tough problems.  THere’s a whole lot more below the surface of that sentence, though.

When we talk about team members doing the right thing, there is an implied “even when it’s hard” at the end:

  • We have the courage to not revert to old habits when work is challenging.
  • We have the courage to not take shortcuts and get work done quickly simply for the sake of getting it done quickly.
  • We have the courage to ask difficult questions when we don’t have all of the information we need to build a product.
  • We have the courage to adapt to change.
  • We have the courage to trust the entire Scrum Team.
  • We have the courage to do everything in our power to meet our forecast and stick to the Definition of Done.
  • We have the courage to commit.
  • We have the courage to be honest about our work.
  • We have the courage to listen to what others on our team are saying, even when we don’t want to hear it.
  • We have the courage to fail, and the courage to admit it.

Some of the biggest issues I have seen with teams who are struggling with Scrum all come down to courage.  It’s very easy to fall back into familiar patterns, and even easier to point fingers when things don’t work.

The ceremonies of the Daily Scrum, Sprint Planning, Sprint Review, and Retrospective all require courage.  For Scrum to succeed, we must be able to talk about things that aren’t going well, and come up with ways to fix them.  We have to be willing to show the cracks in our armor to the team, and trust that the team will help us to overcome obstacles.

Showing work in the Sprint Review takes a huge amount of courage.  We accept that we might get feedback that we may not like, and we go into the meeting only prepared to show work that has met our Definition of Done.  We are not going to show our stakeholders (and each other) work that is half-finished and we are going to hand-wave past the incomplete parts.  We also aren’t going to show stakeholders a chunk of code they don’t necessarily understand; we will only show them work as our users will see it.

We are willing to have an honest discussion every day to inspect our progress toward our Sprint Goals and adapt our plan if we are off track.  We have a cross-functional team that is willing to jump into work they may know little about and get it done, as a team.  We are willing to be honest in our Retrospectives and discuss ways we can be a better team.  We do this without throwing our teammates under the bus, but are willing to share in our failures as much as we are willing to celebrate our successes.

Scrum takes a tremendous amount of personal and team courage.  The courage demanded by Scrum allows us to shine a bright light on every aspect of what we do, to look at it clearly, and always find ways to make improvements.

Part I

Scrum Values I: Today’s Episode — Commitment.

That’s a huge word that carries a lot of weight.  It’s also a word that has had a shift in definition – as it relates to Scrum – in recent times.  So what, exactly, do we mean when we are talking about commitment?

For a long time, commitment meant “I am going to do everything it takes — working 9 days a week, 27.5 hours a day if necessary — to make sure this gets done exactly on time and exactly as described by the requirements.”  For some people, this is still what it means, being on call non-stop, never being able to disconnect, even on vacation, and putting that commitment above all else.

That’s not how this works.  That’s not how any of this works.

Go back to the Scrum Guide for a minute, open it in a separate window or tab.  Got it?  Now search for the word “commitment” in there.  As of the November 2017 update, there is exactly one place you will find it, and that’s in the Scrum Values.  Further, the Scrum Guide states:

“People personally commit to achieving the goals of the Scrum.”

That’s it.

Commitment doesn’t mean we have no life and pull out every single last stop to get everything done exactly as commanded by some arcane (and likely out of date) requirements document.

  • It means that everyone on the team is dedicated to helping the team succeed.  The exact work that will be done within a Sprint can and will change as work is underway, but always with the end desire of achieving the Sprint Goals.
  • It means that if we are behind, the Development Team will sit with the Product Owner and have a conversation to make adjustments to the work in the Sprint so that an increment of working software is done when the Sprint ends.
  • It means that the Product Owner leaves flexibility in his or her Acceptance Criteria so that the team has room for negotiation.
  • It means that the Scrum Master is actively listening and responding to the needs of the team.
  • It means that we are going to do our best, but recognize that if we fall short it will not be for lack of effort.

Organizationally, it means that we empower our Scrum Teams, and give them the resources and flexibility they need to be successful.

When the team sets their Sprint Backlog, we should stop talking about commitment – as it relates to the old way of thinking – and recognize that we are talking about a forecast. Things may change as we get more clarity on any or all user stories in a Sprint.  Things may be moved out, or be added, to allow the team to still meet the Sprint Goal.

That doesn’t mean the team failed to meet its commitments, it means they are being truly Agile.

Bringing the Scrum Values to Life – A Tale in Five Parts.

Scrum Values

One of the best things that happened to the Scrum Guide in the last two years was the introduction of the Scrum Values.  These two very simple paragraphs shine a huge light on things that are crucial to the success of Scrum.  I’ve spent a lot of time thinking about each one, how they impact what we do each day, and want to look at each one in turn.

  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect

Quoting from the November 2017 Scrum Guide:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events, and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

Two paragraphs.  Lots of information to digest.

Rather than writing one large post on why these are absolutely critical, I will take them one at a time – one per day, starting next Monday – and dive into what how each one of these Scrum Values is so important.  These aren’t just words that we can consider and forget, they are imperative in how we create highly collaborative, highly productive teams.  

It’s worth pointing out right here that I actually wrote this first post after I drafted all of the ones that will follow.  One of the best parts of examining each of the Scrum Values, to me, was examining how each one relates very strongly to the others.  Considering each individually, it becomes clear how all five are tightly connected, and provide crucial pillars upon which Scrum is built.

This should be fun!

Shhh… the strength of silence


Picture this:  Your team (or someone on the team) comes to you looking for help.  You are asked a question.  What do you do?

You answer it, right?  That’s the normal response.  By nature, we want to help others (well, most of us do), and that means answering their questions, and sometimes even rolling up our sleeves and helping with the actual work.

How about this situation:

You’re facilitating a Retrospective for your Scrum Team and you ask them a question. Nobody answers.  Maybe your question was too hard, or they aren’t comfortable providing the answer, so you wait a short amount of time and start talking again, either giving them the answer, leading them toward the one you have in mind, or changing the question to make it easier.

So what if I were to tell you that might be the wrong thing to do?

As a Scrum Master, one of the most potent tools you have is silence.  Keeping your mouth closed is easy, but it’s also one of the hardest things to practice and teach yourself.  I had to fight every instinct to learn this one, and I still find I need to catch myself on a regular basis.  Being quiet takes work!

But here’s the thing: When you become comfortable with your own silence, you allow your teams to grow.  When a question is asked — whether in a team discussion or in a one on one setting — don’t answer right away.  However long you think is a good pause before you answer, wait three to four times that long.  Let the silence get uncomfortable, and read the energy of the room.

Don’t focus on the fact that you aren’t talking, focus on how people are reacting.  Read their body language and listen to what they are not telling you.  You will naturally start to come up what your answer might be – resist the urge to do so!  Keep yourself actively listening through the silence.  Shift all of your attention from your instinct to speak and keep it completely on your team.  Make eye contact, smile, and let the silence hang.

When you do this, one of two things will happen:

1) You give yourself extra time to compose your response and make sure you and giving the right answer (or asking a better question), should you choose to do so.

More often, however…

2) The person will provide their own answer, or someone else on the team will, allowing you to stay in active listening mode and feeling where your input is actually needed!

We don’t like silence. Most people will instinctively try to fill the silence by speaking up, rather than letting that awkward, uncomfortable silence linger.  You will be surprised at how often they will answer their own questions, or at least come up with a more insightful question than the one that was originally asked.

Your knowledge, experience, and insight is important to the team.  Your silence can be even more important.  In that awful silence, they have the opportunity to stretch out beyond their comfort zone and to grow.  The trick lies in knowing how long to let that silence hang, and when they really do need some of your sage-like wisdom.

Growth happens in those uncomfortable moments.  I’ve joked with my teams more than once that when I see they’re in that uncomfortable space, I cackle with glee on my commute home.

Silence is powerful.  Make it a part of your toolbox and see where it gets you!

Dancing through chaos and how to avoid the Coaching Death Spiral


First things first.  This entire post was inspired by an even better one by Stephanie Ockerman.  If you don’t already read her blog, you need to fix that right now.  She offers amazing insights and is an incredible voice for Scrum.

If you just left this page to go read everything in her blog, I don’t take offense.

She describes a pattern early in her post that really got me to thinking about my own coaching style and where things can go wrong.  I call this the Coaching Death Spiral, but feel free to come up with whatever better name suits your purpose.

In short, here’s the Death Spiral pattern:

  • We enter a coaching event with some degree of expectation and things don’t go quite as expected.
  • Because things are not what we thought, we doubt ourselves; not sure if we are asking the right questions and saying the right things.
  • Once that doubt sets in, we overthink everything.
  • We become so involved in our own heads, that we aren’t actively listening anymore.
  • We now start missing important cues in tone, body language, or even in the actual words someone is saying
  • Effective coaching has stopped; we’ve lost the person we are supposed to be coaching.

You can see how each step in the spiral feeds off the one before it, and that once you start down this path, it can become very difficult to escape.  I’ve done this, and I’m quite confident in saying that I will likely do it again, even knowing what’s happening.  We’re human, and these things happen.

What’s really important is to recognize what can happen, and think about how we avoid it in the first place.

It all starts with those first two lines.  If we go into any coaching event with some preconceived expectation of precisely how things will unfold, we set ourselves up for failure.  No matter how things go, the fact is that we won’t always ask the right questions, or have the just exactly perfect thing to say at any given moment.  Every single coaching conversation is different, even when you’re coaching the same person on something you’ve coached them on previously:

  • The context for that conversation has changed
  • It’s a different time of the day
  • One (or both) of you didn’t get a good night’s sleep, or hasn’t had enough coffee yet.
  • There’s a bad moon on the rise

Whatever the circumstances might be, there is always something different and unique about every single coaching event.  Going into coaching with any kind of fixed agenda simply isn’t going to work, because you don’t have all of the information you need until you’re well into the event.  It’s okay to have some thoughts in mind, but those might not actually be what the person you’re talking to needs in that moment, and sticking to your talking points could lose the person just as quickly as getting sucked into the Death Spiral.

It’s chaos, I know.

To quote directly from Stephanie’s amazing post: “We must be willing to dance in this moment.”

I LOVE this.  And Stephanie, if you’re reading this, thank you for that line because that’s the one that inspired me. 

You are going into a coaching event with someone — whether one on one, or in a group setting — and you don’t know what’s about to happen.  Putting time aside to work with someone is no different than putting your name on their dance card at this point.  You’ve got time on their schedule reserved, and the dance begins:

  • When the conversation starts, the musicians have begun to play..
  • Take your partner and start to dance.
    (Not literally. It might be weird. Unless you actually work in a dance studio.)
  • You don’t know what the band (or DJ) is going to play next, just as you don’t know where the conversation is going to go.
  • You know you want to keep dancing with this person, so you adjust.
  • During any given dance, you don’t know exactly what you’re going to do, you just know you’re going to move together and share that moment.
  • You will take cues from your dance partner.  Sometimes you will lead, sometimes they will lead, and it will all work out great.
  • Those cues might be verbal, they might be from making eye contact, they might be in how they are actually moving.  All of these things are important.
  • The dance can create an emotional connection.  Don’t shy away from this!
  • You may be tired when you finally stop, but it was worth every minute.

Be in the moment.  Enjoy the dance, and pay attention to what your dance partner is doing.  Listen to everything they say, and more to the things they don’t.  All of these things will give you important clues on what that person wants or needs from this time.

Be there with them.  Take your cues from everything the person you are coaching is telling you.  You don’t have to get it perfect every single time, but you do need to be in the moment with them, and willing to take them out onto the dance floor and spin around a few times.


Exposing our faults, and learning to embrace the pain

I recently heard the following statement:

“Scrum does not solve your problems, it exposes them.”

That simple statement is incredibly profound, and it struck me immediately.  Read it again and let it sink in.

That simple sentence cuts right to the heart of things. Too many times, I hear from teams that they wish they had a finalized design before they start coding, or a fully defined architecture and detailed plan for the next several weeks.  I have seen crestfallen looks, heard audible sighs, and witnessed eyes rolling when I have to gently break it to them that these things just won’t be happening.

That’s not how any of this works.

Scrum works not because it’s a magic bullet that will suddenly make everything in your dev shop perfect.  It works because it shines a light on where the problems are and empowers you to make the corrections that you need.  It gives us, as a Scrum Team, opportunities to continuously inspect our progress and make adjustments.  It encourages all of us to try things, and gives us space to fail.  In fact, a certain amount of failure is a good thing.  When we look at all of the Scrum ceremonies (Daily Scrum, Planning, Review, Retrospective), we see a chance in every single one to make changes based on the empirical evidence of how the team is performing, and the challenges they are facing.

That doesn’t mean it’s easy.

We aren’t comfortable seeing our problems and facing them.  Our instinct is one of preservation, and you’ll see team members get defensive when the weak spots are made visible.  I’ve seen all of these things happen:

  • Members offer excuses for why something went wrong, rather than working on solving it.
  • People wish we could “do things the old way”.
  • Team members get angry, or worse, throw another member of their team under the bus to protect themselves, because they feel like there is a risk in being anything less than perfect.
  • Your coaching skills will be tested to their utmost.

I can say, from experience, that there have been moments when I’ve been tempted to just walk away from the hard work because I feared confrontation, or had reached the end of my rope with someone who just didn’t seem to get it.  Scrum exposed MY problem, and I was able to step back, reflect on what was actually happening, ask myself the 5 whys, and come up with a way to work through the issue and get everything back on track.  I can honestly say that I am a better Scrum Master because of it.

This was HARD.  

Seeing team members going through the same thing – team members you work with every day and have a professional relationship (if not a true friendship) with – is no easier.  Because we care about our teams, we want to protect them from all of these issues.  In truth, we aren’t doing them any service by shielding them from themselves! Yours is the voice of reassurance.

Fortunately, we have plenty of tools at our fingertips to help us with all of these things…

Agile Transformation II – In which a failed transformation was rescued!

“Scrum is Hard and Disruptive” - Ken Schwaber

If you didn’t read the first part, I would suggest that now would be an excellent time to do so.  It’s certainly not required, but it will provide context for this post.

Go ahead, I’ll wait.

So here we are, in the throes of a soul-killing transformation to Scrum that wasn’t actually one.  The general feeling in the Development team was to throw Scrum out as a total disaster and go back to what we were doing.  Even when we knew that waterfall was evil, it was at least kind of functioning, and we were putting out working software sometimes.

But there were rebels.

Rebels who were familiar with how Scrum is supposed to work, or who spent some time with Google and learned, knowing that something was terribly, terribly wrong.  Many a blog was read, many a book was purchased and consumed.  And a plan was slowly concocted.

Before I lay out this nefarious plan, a caveat.  I don’t actually recommend this plan.  It worked for this group of rebel scum, but we got lucky.  And yes, I was most certainly one of the aforementioned rebels.  While we were sure it would work – and ultimately it did – it could just have easily exploded in our faces.  

In order for the nefarious plan to succeed, there first needed to be a critical sea change.  At the top of the management chain.  A new executive joined the company, and brought new energy along with him.  This forced the VP oft mentioned in the first post to back off, and paved the way for change.  (The VP was, in fairly rapid order, no longer with the company).  A true Agile transformation needs to have buy-in vertically throughout the organization.  It’s not necessarily top-down, but top level management has to be on board.

We didn’t actually do that, instead deciding that we would rather ask for forgiveness than permission, and we acted. The words “Agile” and “Scrum” were poison, so we had to spin it and take a different approach.  How to get the team to embrace Scrum, without ever telling them what they were doing?  Almost every term associated with Scrum was out.  We needed to be stealthy and get everyone on board with the idea of just being awesome again, and let’s try things to do that.  But this time, rather than coming from a VP with a decree, it was coming from two or three peers who just wanted us to be great and have fun.

We liked the idea of Sprints.  That’s literally the only thing we kept completely intact, setting a consistent two week cadence.

We recognized that the one ceremony people felt was at least sort of useful was the Daily Scrum.  Our first step was to just call it a stand up, which is not uncommon, and to change how it was run.  Hours were obviously gone.  We moved to an actual board, and we suggested that we change the conversation to a story by story basis, rather than focusing on individuals.  The Three Questions were history.  This took the pressure off people and refocused the conversation on the actual work, and how things were progressing.  I became the Scrum Master, but to the team, I was just the guy facilitating the meeting.  There was to be no mention of the word Scrum.

The 20 person Dev team was divided into manageable sizes.  Some of this was done from management (definitely a Scrum anti-pattern), but for now, we were fine with this compromise.  The teams weren’t in a place to self-organize at that level yet.

Retrospectives had to be completely overhauled.  For a long time, we didn’t do them.  When we started to notice that the teams were starting to talk about how to improve, we jumped.  We started post-mortem ceremonies at the end of every sprint, before we did any planning.  We stopped just going around a table and asking people what they thought, but started to make things more open-ended, giving team members a chance to have a discussion, and asking thoughtful, leading questions to steer the discussion toward arriving at SMART goals on how to adapt going forward.

Sprint Planning became a real thing, and the team became engaged and involved with the work they would be doing.  To begin with, estimates were out the window, because we wanted to break the habit of trying to break down everything into hours.  We simply asked the question “What do think the team can complete during this Sprint?” and built the backlog accordingly.  Burndown and Burnup charts weren’t important.  All that mattered was that the team agreed on what they could do, and that they got it done.

At the same time, we started to preach two important things to the teams:

  1. It’s okay to fail.
  2. It’s better to under-commit and over-deliver than the reverse.

We did shorten to one week Sprints for a long time, to help establish cadence and the discipline of limiting work to what could realized during the sprint.

The energy began to change, and the team was feeling like they could do anything.  Everyone was talking, instead of building silos and sulking.  People were excited about what they were accomplishing, no matter how difficult the work.  Our Product Managers became actual Product Owners and were integral parts of the teams.

We were learning together, and helping each other along the way.  If you fell, there was someone there to pick you up and help out.  The basic “Cover Your Ass” mentality stopped, and the teams began thinking of themselves as teams!  This was the breakthrough we were waiting for!

Somewhere around here… we let the cat out of the bag.  The team was (mostly) doing Scrum.  We just weren’t calling it that.  But this was now a good time to start using the right language, and to look how far we had come as a group!

We might have been called sneaky bastards.  We might have high-fived immediately after that.

Somewhere during this process, we introduced CI builds.  We introduced nightly full staging builds for QE.  We started writing unit tests, and showing them to everyone like we had just made a new discovery.  Not everyone bought into unit tests right away, but they saw how they could be awesome.  (We also got heat from a senior engineer/team-lead type for bringing unit tests into the picture without asking him first.  I suspected it was because he was afraid testing might uncover how fragile his code was, but have no proof of this).  We got people thinking about how to refactor code, and that spending time writing clean code up front was better than writing something quickly and ending up with a code base more unstable than a house of cards.  Tech debt started to slowly get paid down, and engineering practices leveled up!

All that said – this was not easy!  There was a lot of work that went into making these changes, and it had to be done with care.  We were met with resistance on many levels.  We were challenged on almost everything.  Some people just didn’t get it, others didn’t see the value in what we were trying, others probably saw through our thinly disguised charade and declared there were shenanigans.  You know what?  All of those people who resisted were right to do so!  We barely had permission to do what we were doing, and the approach we took flew in the face of any so-called conventional wisdom.  There were many days when we were just making it up and seeing if it worked, and sometimes it showed.  But we eventually got there, and created high-performing Scrum teams out of actual chaos. 

Don’t be afraid of tumult!  Instead, see how you can harness it within your organization to push toward your ultimate goal.  We recognized the chaos we were left with, came up with a plan, and worked slowly and calmly to create something awesome out of that initial chaos.  Use the energy that lives in the tempest to create your own awesome!