What did the team say?

I’m posting this on behalf of a guest this week who is not quite ready to “go public” yet.  Happy Monday! – Valerie

As a new Scrum Master, I have had the extreme fortune to have a personal Agile Coach guide me.  Well, she’s technically not my personal coach, but with the attention and information she has given me, it sure feels like it.  In a previous blog post, she stated she wasn’t sure what she taught me.  Well I can tell you that.  She taught me to “ask the team”.  Seems simple enough right?  Well it’s not.

I knew the number one job of a Scrum Master was to protect the team.  No problem.  I’m good at that.  I love being the person people can rely on.   Co-workers, family, doesn’t matter who.  If someone is having difficulty, I want to solve their problem.  I want to fix it.  You want me to be a Scrum Master?  You bet!  I got this!

Well, in some situations solving the problem works just fine.  But as a Scrum Master, well….. not so much.  You see “fixing it” doesn’t help anyone in the long run.  Plus, even if I wanted to, I couldn’t do the teams’ job for them.  I don’t have the time, or the ability.  These folks are smart!!  They have mad skills that I can’t even comprehend.

So, I found myself in situations where I wouldn’t know the answer to a question or a problem and I’d run to my coach.

 Me:  Okay, here’s the problem.  What should I do? 

Coach:  What did the team say you should do?

Me:  I don’t know, I didn’t ask them.

Coach:  ***silent stare***

We had this conversation more times that I can count.  I couldn’t understand how I was helping the team unless I fixed the issue for them.  After all, if they knew the answer, they wouldn’t need me!  I finally understand that this is exactly the point.  The ultimate goal is for the team NOT to need me.  A Scrum Team is supposed to be self-organizing… not Scrum Master organizing.  If I do my job well, they will eventually no longer need me.

So that’s the scary part.  What will I do then?  I know what I’ll do.  I’ll move on to another team and do my best to make sure they eventually don’t need me either.  Or maybe, just maybe, I can start my journey to becoming an Agile Coach.   I can talk future Scrum Masters down from the ledge by explaining to them they don’t have to fix everything.  I’ll explain to them they should work to make sure their teams can work efficiently without them,,, just like I’ll make sure the people I’m coaching can work efficiently without me,,, just like my coach has been doing for me all along.  So thank you!  With your help, I got this!

And here’s the best part.  I’ve talked a lot about not “needing” each other.  The reality is we will always still be there for each other.  Even if my teams don’t need me on a daily basis, I’ll still be there for them.  My door will always be open.  My coach’s door is always open for me too.  I know this, and I will walk through that door from time to time.  I’ll just make sure before I do, I have the answer ready to the first question she’ll ask me.  “What did the team say?”

Advertisements

Can you put an estimate on the value of conversation?

Some time ago I heard about a trend of “No Estimates” and, have to admit, was not happy about it.  The reason I wasn’t happy about it had nothing to do with understanding the velocity of a team.  It had everything to do with the team missing out on critical conversations that occur when arriving at an agreed upon estimate.  I love watching new teams estimate stories.  When someone throws a 20 and someone else has a 5, the discussion that takes place – THE LEARNING – is pretty powerful to observe.  Estimating is a way for team members to get to know one another better and understand how they each view things differently.  Eventually, they start applying others’ perspectives to their own and the team truly finds a voice as a single entity.

Dan Mezick wrote a good blog post recently and pointed out “One may say with some certainty that the estimation task is actually a ‘cover story’ for the wider task of team learning. If estimates are 100% eliminated, how is this team learning replaced? Team learning is obviously essential. Discussions during the estimation task create many team-learning moments.”

Frankly, I believe a team, who is committed, will get to a point where estimates are not required.  This will happen once they learn – not before.  Scrum has estimates and the concept of velocity there for a reason.  A team must go through Shu (Follow the rule) before they can muck around with it and find something else that works best for them or reach a state of Ri (Make the rule).  If you start a team out with no estimates, I believe the learning curve and reaching a performing state will be delayed.

Some teams use relative estimation.  Others will use Planning Poker.  Heck, I have seen a team estimate in “farm terms”. Seriously.  A duck is less than a cow which is less than a barn and so on….  It worked for them.  Who am I to question it?  So, yeah, maybe this idea has merit but, I really would caution against giving it a go with a newly formed team.  Sound snippets like this one make me a little nervous.  You can’t place a value on the conversation that takes place during estimation.  You CAN place a value on a team taking twice as long to reach a performing state.

An Open Mind is a Terrible Thing To Waste

I was given some really good advice tonight:  In every situation you find yourself in, no matter how many times you have seen it, you must treat it like it’s the first time.  You need to look at it with fresh eyes and try to remember what it was like, for you, the first time. I just loved how that was put.  Once you have gone through the “same” process enough times, it would be easy to become a little numb to all the dynamics in play.  It may also be easy to be a little insensitive to those who are experiencing something for the first time.  As a Scrum Master, having an open mind is critical.

I know, personally, I have been put with new teams – just coming together and finding myself less patient with them because I KNOW what’s coming.  But, really, I don’t.  I mean, it may be fair to say that I know where they will end up but that’s not the important part when a new team is coming together.  It’s HOW the team comes together that’s important and, if I’m less patient or dismissive, that can really impact the HOW and can also completely negate my “where they will end up” comfort.

There was a team I worked with a long time ago and the set up was somewhat screwy.  Despite having learned that I don’t know it all several times over, when this team started, I wasn’t in the right frame of mind.  There was a lot going on for me and I wasn’t invested in them.  I wasn’t really there to help them.  I dismissed their concerns and told them to “trust me”.  Rightfully so, they didn’t.  Why should they?  I was very clearly not engaged.  My mind wasn’t open to them and theirs sure wasn’t open to mine.  This team was completely new to Agile and I was doing them a disservice.  I didn’t want to go through their phases with them.  I wanted them to hurry up and get there.  You can imagine how well that worked out.  It didn’t.  Not at all.

I did recognize it and made moves to correct it quickly but, it didn’t matter much.  They had no reason to trust me, value my opinion or seek my advice.  What resulted was dysfunction at my hands.  It was a complete waste of an opportunity for them and for me.  A Scrum Master has a special relationship with a team because her focus is the team.  She can shape the safe environment teams need to learn and grow.  She can guide them through learning Scrum and help them chart their course to greatness IF two things are true:

1.  The Scrum Master has opted in and has an open mind to her new team.

2.  The Team has an open mind with regards to the Scrum Master and tackling Scrum.

I believe, if you begin with an open mind, there’s a bigger potential for greatness.  With an open mind you listen with the goal of understanding.  Being open automatically requires courage which is definitely needed when charting new territory.  Openness allows you to view your team positively.  Openness nurtures trust. When you’re listening, exploring, trying, brainstorming with the team, you’re building that trust and camaraderie.

As a Scrum Master, when you find yourself in a new environment or situation, don’t bring the events of the past with you.  Open your mind to what is possible.  Keep your eyes wide to observe and listen.  Remember that, though familiar, it’s only familiar to you.  Explore the solutions with your team with minds wide open and you’ll find the journey will be full of learning for everyone.  Even you, the Scrum Master who (thinks she) has seen it all.  Every team is different and so is their path.  Be open to their adventure.

So many options….so little time. What to do? PRIORITIZE

So often I am amazed at how much I learn with regards to Agile that applies to my own life.  Most recently, prioritization was front and center.  I had a difficult and personal decision to make and I was truly struggling with what to do.  I was torn and, frankly, I didn’t want to decide.  I wanted to have it all!  ( Now if that doesn’t sound like some Product Owners and Business Stakeholders I don’t know what does.)

I reached out to someone I thought could help and, what do you know, he did!  How I got to meet this mentor is a great story which I’ll save for another time.  Anyway, his guidance was to sit down and not focus on my decision.  Instead I was to focus on my longer-term vision.  Now, I will say my vision is still a work in progress, so don’t think you can just bang out a vision in 10 minutes and be done with it.  Once I had the vision (in pictures ONLY) he said to put words to it and really think about what was non-negotiable, open for discussion and nice to have.  Then, take the opportunity I was considering and compare it to the vision and the words.  I did as he suggested and my decision was clear!

In delivery, when you know your long term objectives or vision, it’s MUCH easier to prioritize all of the cool things you could possibly do.  If the vision isn’t clear, well, you could spend a lot of time, effort and energy on something that won’t bring you closer to your vision and that’s not OK.   It’s not OK for the team, for the users OR for the business.  If you’re not spending energy on things that bring you closer to your vision, the odds are good you’re spending it on things which will (likely) take you further from it.  The true waste is you won’t know until you’re so far away and it will be harder to to get back on track.

It is a little shocking, when I think back on all the teams I have worked with, how many times I have heard “We HAVE to have EVERYTHING!”.  Funnily, in our own lives we know having it all isn’t generally possible but, in work, it can get dangerously close to normal.  And, how is that acceptable?  It shouldn’t be.  There should be uber-clear goals a company is trying to reach and the things they are trying to do should enable getting closer to the goal.  A Product Owner who doesn’t understand the vision will not be able to explain the context to the team.  This means it will be ridiculously challenging for the team to work quickly and efficiently.  Without context, the how becomes guess work.  If the Product Owner doesn’t understand the vision, there’s not a snow balls chance he will be able to effectively prioritize leading the team to work on things that aren’t valuable.

As a Scrum Master insist on the Product Owner reviewing the vision with the team.  Allow for an appropriate amount of time to ask questions.  Encourage the team to understand the thinking behind the prioritization and to challenge and suggest things to be considered by the Product Owner. This is the environment to strive for.  Mutual understanding and benefit. Understanding the vision and fostering this type of relationship with the Product Owner is powerful.  It’s powerful enough to allow a team to take off and deliver amazing things.

It still hurt to make my decision.  I really, really wanted to give it a go.  It wasn’t the right opportunity at this time in my life and I was able to be at peace with it.  Of course I want it all.  Who wouldn’t?  That said, knowing the context of how that one “thing” fit into the larger picture was critical to me.  Understanding the product vision and the resulting prioritization is one of those concepts where everyone will nod their heads and say they get it but, do they?  Do you?  We need to focus on the right things so we are always getting closer to the vision and doing amazing things.  As close as we possibly can anyway until we’re satisfied.

Value is POWERFUL for people and work

In the last week I have been hit hard by the reminder of how powerful value is.  There are two instances I want to highlight.One is related to people and the other related to stories.

VALUE YOUR PEOPLE

It’s important as a Scrum Master, a people manager or a leader to show the people you work with and for that you value them as a person and for the work they do.  When a person feels valued, they are motivated.  And, I know, everyone is motivated by different things.  For some, it’s money.  For others, it’s recognition.  There are many things a person may be motivated by but, all people need to feel valued.  If they don’t, they disengage and that isn’t good for anyone.

You need to find out what is unique in the people you are surrounded by.  It doesn’t matter if you manage them, lead them or work for them.  Identifying what makes an individual special is powerful…for them.  You can find ways to build on it, leverage it, showcase it and help the person shine.  When you make someone feel valued, they will return it with awesome performance and, even better, loyalty.  If you’re not investing thought like this into your people, please, take some time to do so.  Have a conversation.  Find out what they’re passionate about.  Discover what they’re good at doing.  Learn about what they want to learn about.  Invest in and value people and the dividends are endless.

VALUE STORIES

People want to be valued and they want to work on things that are valuable.  In a SAFe release planning event this week teams had identified the features they were delivering and broken them down into stories.  In SAFe, teams then specify their release objectives.  It’s a layman summary of multiple stories which, Product Management then values on a scale of 1-10.  Keep in mind teams are working in priority order so, the initial thought is their focus is on the right features.  When you break a feature into stories and specify exactly what the objectives are for the release, what happens is amazing.  A conversation with a group of Product Managers and the team takes place and, often, a high priority feature has objectives associated with it whose value is mixed.  We’re all about delivering value right? Here’s an example over-simplified:

EPIC – Build  house

Feature – Build Front Entrance (priority = 1)

Feature – Build a Deck (priority -2)

Objectives –

–  Complete deck to hold more than 6000 lbs. – 9

–  Complete steps to front porch – 10

–  Complete front porch covering – 4

–  Paint front door – 1

– Complete rails around deck – 8

– Build grill bump out – 2

When you look at it, there’s more VALUE in completing items associated with the lower priority feature.  Good to know for a team.  Very enlightening to Product Management.  Awesome conversations and understanding generated between delivery and the business.  All is all, just goodness.

In summary, there’s power in focusing on value – for the people and the work.  See what you can do tomorrow for people.  Make someone’s day.

The Bond Between a Scrum Master and The Team

I was asked yesterday to describe the difference between a Scrum Master and a Project Manager and an odd metaphor popped in my head.

When a team has just won a game and the coach is interviewed afterwards they don’t say “Yep.  The team followed my instructions and plan exactly.  They executed what I wanted them to, when I wanted them to and how I wanted them to.  That’s why they won.”

They say things like “The team gave their best today.  They have been working hard together all season and, today, it all paid off.  They were amazing out there.  They deserve this win.”

I’m not saying a PM would actually take credit for the end-product of a team.  I am saying that the coach puts the emphasis on the team and the PM puts an emphasis on the plan and the execution of it.

This mind shift is essential and not an easy one.  I have found the relationships between me (as a Scrum Master) and the teams I have worked with are all very different with one exception.  Every single one has been based on trust.  When there’s a strong bond between a Scrum Master and the team, from my point of view, there’s nothing more fun or cool.

The team helps you grow by challenging you to be better and think differently. Their learning outpaces your own!  And they’re learning because they trust you, their Scrum Master, to make good suggestions and they’re willing to try things.  Sometimes, in my head, I will think “I dare you to be even better than you already are.”.  You can see them as a single entity and the possibility of the whole.

Scrum Masters also connect with the individuals on the team.  Many of my good friends are from previous teams and they are not people I would have known well had we not worked so closely together.  A Scrum Master can see things that are possible in an individual that the person may not even be able to see.  The same is true for the team member.  Often, team members have taught me things I never would have thought about or seen in myself.  Some good and some not so good but all said with the best of intentions.  The team members and the Scrum Master can help each other learn and grow individually.

I can’t speak from the team member perspective on this final point.  I feel very protective of my teams.  When they have great things going on and happening, I want everyone to see how awesome they are.  When people are messing with them, in any way, I feel very Mama Bear.  I may actually get a little too “bear”.   When they achieve greatness, I don’t want anyone or anything in their way.  When they’re on their way, I want them to have the space and room to work their way towards it.

When people ask me now why I am so passionate about Agile, the answer is simple.  It’s the people.  I can name them all.  I can tell you why each one is special.  I can tell you everything each one of them taught me.  The bond is built on trust and is powerful because you learned so much with each other.

What’s wrong with having a paper trail?

A friend of mine did an informal poll today:

If you need three pieces of information quickly, what’s your preferred method of getting them?

a.  Phone call

b.  IM

c.  e-mail

What’s missing from the options?  Face to face communication didn’t even make the cut!  The people who responded generally preferred e-mail and IM due to having a paper trail to CYA.  Seriously.  I get it.  I do.  The difference for me now is perspective.  Why the need to CYA?  Why not EYA and own it?  If a paper trail is necessary, the problem isn’t anything other than the culture that exists is one where covering your ass is necessary.

Channeling someone else here…..  that just makes me sad.

A Scrum Masters job is to work themselves out of a job

I didn’t realize this when I first started on my Agile journey but, it’s absolutely true. We talk about self-organizing, self-managing teams and I continue to see teams and Scrum Masters who can’t separate. I think some of it is organizational and some of it is…not.

When a company or department decides to “go Agile” they do it for the right reasons. They want to deliver value faster. The thing is, when you apply Scrum, it’s a massive mind-shift more than anything else and while the org may want to deliver faster, they still want all the other stuff they had too. Things like status reports, project plans, milestones…I have had people ask for the release plan .mpp. I understand the needs of stakeholders and executives but you can’t have it both ways. Don’t get me wrong, there’s a compromise to be had if the company is large enough. Lately, I’m thinking frameworks like SAFe address those needs nicely – we’ll see. So, you need a Scrum Master to deal with the paperwork overhead. If the Scrum Master is meeting this need they’re probably not focusing on getting the team to a high-performing place. Odds are pretty good the team is still working in the old way, just with a board.

The other reason could be that it’s mostly PMs who end up filling the Scrum Master role and unless he or she is willing to really shift perspective, it’s command and control with a team in the room and the plan on the board. It’s awesome for the PM!! Their team is captive and he can tell what is going on every minute of the day. That’s horrible for the team though. And, that PM is not focused on the team. He’s focused on the work.

My initial point of view was it was business as usual, but with a board and 15 minute meeting everyday. I NEEDED to know everything, control everything and be right smack in the center of everything. A good team, mentors and instructors taught me differently. It’s great when you deliver a project as a PM. But, let me tell you, it’s nothing short of awesome when you guide a team to that self-organizing, high-performing place and you realize you’re no longer necessary.

People are smart. They want to do well. They have good ideas. They are good problem solvers. These are basic truths. Team members will work hard for each other, their solutions and their ideas. To me, the job of a Scrum Master is to help the team learn how to do all these things within the Scrum Framework as simply and easily as possible. It’s not so much about protecting them from others. It’s about protecting the space they need to learn, grow and get to a place where you’re not needed.

Creating a Team Vision

One of my favorite exercises to do with a new (in general or new to me) team is to have a team vision session.  Generally, I start with laying out what being a team means – A single entity working towards a common goal.  I lead a discussion on what high-performing teams “look” like and the characteristics they exhibit.  Then, we talk about what each individual has a goal for the team which usually generates some good conversations.  From there I move into the team vision exercise.

What do you want this team to be known for?  When people outside think about this team, what do you want them to think?

  • Have the team divide into two groups
  • Give them 5 minutes to work together and think about the answers to the above questions and creating a team vision description
  • At the end of 5 minutes, each group presents to the other and the non-presenting group asks questions and calls out what they like about what they’re hearing
  • After each group has presented, the full team works to create a joint vision based on the smaller group exercise.  They can pull from the discussions we had earlier, the outputs from their sessions and anything else they want to have incorporated.  It’s time-boxed to 5 minutes.

At the end, when they’re happy with their vision, we have a conversation about who is accountable to vision and how they will use/incorporate it into their day to day.  The final vision is posted in the room.  I use this to generate retro topics, re-visit team norms and a whole host of other things. I have found that team members will use it immediately with each other when they’re discussing approaches, establishing their sprint goal and working through conflict.

They created it.  They own it.  It’s their job to work together and strive towards their vision.

It can be powerful.  Let me know if you try it and whether or not it was a good use of time.

Optimize The Whole

When moving to Scrum we ask for a lot from the team members.  We ask them to be transparent with their work, stay focused on their commitment to the team and BE on a team among many other things.  While it may seem straightforward it’s really not.  A team is a single entity.  Each team has a unique and individual identity.  It’s about the whole.  For a high-performing individual, it feels like being a part of a team takes away from their status as a high-performer and the rewards that come with it.  Rather than a stand-out individual they’re on a team which may or may not be standing out.  It can feel kind of terrible for that person.

Being on a team takes a special kind of courage.  There’s faith involved.  One must be humble.  The teams needs must come before the needs of the individual.  As a Scrum Master, you can help the unique contributions of the individual bubble to the surface.  This enables the other members on the team to see what’s special about their team mate and leverage it for the greater good. The team won’t know you’re doing it but, they will see the fruits of your efforts and they’ll begin exploiting the awesomeness of their team mates on their own.  You will hear them recognize each other in Demos to stakeholders or just to each other.  What comes from this is pure gold on a team.  Now you have loyalty.

How do you do this as a Scrum Master?

  • Observe and listen.  There’s so much that gets missed in a conversation you’re participating in.  Participate in a different way and find the awesome in each individual on the team.  Then, look for ways to introduce it to the rest.
  • Have the team do an exercise to write down their skills and knowledge and let them all see how much more each of them brings outside of their traditional role.
  • Make the environment safe and foster the trust.
  • Reward and recognize acts of courage, humility and brilliance.

Optimize the whole of a person so the team can do the same.

Trust  – Courage – Loyalty – Awesome