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.

My Light Bulb Moment

Thanks to Michele Sliger for asking me to write it all down!

I started out as an ”Agile Project Manager”.  I accepted a contract for an IT project (my first) and was told it would be run as an Agile project.  I had no idea what Agile was and I was a Project Manager.  I had a great track record as a PM of driving results.  I googled Agile and was thrilled to learn my entire team would be in the same room, everything they were doing would be on the board and we would only have a 15 minute meeting once a day to discuss the project.  Oh….how very wrong I was.  Mind you the team delivered after slogging through entirely too much overtime, continuous pressure from me and the business and constant driving.  Unfortunately, their work never saw the light of day – two weeks before launch, the project was pulled.  What had worked for me before didn’t work this time.  I heard a lot from the people on the team who knew what Agile was and I was decidedly NOT a Scrum Master.  I cared, a great deal, about the people on the team and there were certain things I began to grasp but not enough to make a difference for them.  Honestly, why I stayed in IT after that project is beyond me but, I did.

Following that project, the next team I had was already formed and doing well on their own.  I still hadn’t had any training but, was asked to be the Scrum Master.  I started reading more and asking more questions of those around me who seemed to get this whole Agile thing.  I came into the team sure I would make them different and better.  I came in without acknowledging or respecting their history.  I asked them all kinds of questions about the work they were doing, why they were doing things the way they were doing them, pushing them a little so, in short, I didn’t really learn much and it still wasn’t clicking for me.  It was not a very comfortable place to be for anyone.  Then, someone had the brilliant idea to combine two teams together – mine and another – and that was when things started to get interesting.  The team that joined my team DID get Agile and they were not at all OK about how I was running them.  They pushed back.  I went to CSM training.

Joe Little and Jeff Sutherland were teaching the course and, as I sat there, all the pieces started coming together.  I understood how it was supposed to work and how I wasn’t doing anything AT ALL to make it easier.  Jeff Sutherland made the point that I still true back to all the time:  Protect The Team.  I came back to work energized and excited.  It clicked and I couldn’t wait to get going.  That said, there was this HUGE team which was really two teams trying to keep their individual team identities in place and continue to be the good teams they were separately.  It wasn’t working. I knew, in theory, what I was supposed to do but I didn’t know HOW to do it.  They fought over desk position, norms, how stand up should be run, how planning should be run and we were all incredibly miserable.  I thought I was doing the right things and protecting the team.  I wasn’t.

I asked another Scrum Master for help.  He came to observe a retro and, at the end of an hour, told me I couldn’t stop.  I had to keep the team talking for as long as it took for them to work their issues out.  The retro lasted all day.  Seriously, all.day.long.  Everyone was open and honest including me.  There were things said which were really hard to swallow for me.  I really had been trying to do the right things.  They made me question everything I had ever thought about my abilities. However, after that retro there was something different.  We all realized we were all trying to do the right things.  There was no malice or ill intent.  We trusted each other a little and we had overcome a decent amount of pain together.  After that retro, I started reading, researching, asking and experimenting and the team let me.  I would tell them what I wanted to try and why and I knew they would tell me when I was off track. They would tell me because they knew I was trying and I wanted to get better.  They also wanted to be better.  We all wanted to be the best team possible.

So, we’re all on an upswing now and someone decides to split the team back up.  Yes.  After ALL that pain we needed to split.  I remember being in the room with several other people figuring out who would go where and they were all looking at me to make the new teams.  It tore me up though.  I had gotten close to everyone and they were doing so well but, I did it, and I chose the team I was going to stay with.  The team was named BOB.  We worked together for about a year and it was the single-most rewarding and fun time of my career.  What I learned from that team in terms of trust, what empowered teams can do, what protecting a team meant and what the role of a Scrum Master really was is what has shaped me and guided me to where I am now.  It is an experience I hope everyone working in Agile can have.

We were nearing performance management time and I was writing my self-appraisal.  I didn’t have anything to write.  I didn’t have any results.  There were no “BIG WINS”.  In fact, I sat there thinking I hadn’t had to do much with the team at all.  I started to get truly worried about what was going to happen come end of year.  With none of the usual problem-solving, risk mitigating, implementation strategizing and scheduling management-type-stuff my piece of paper looked really empty.

“Scrum Master for a team who has delivered more scope than originally requested within the same amount of time.  No defects released into production.  Team has created automated test harnesses to enable faster identification of defects and leverage the QS resource more effectively.  Team members have learned new skills to be more efficient in their delivery approaches.  The team manages themselves, including removing most impediments. The team has created a build book to be used by the platform and serve as guidelines for UI development.  The team is able to respond quickly to change and is frequently sought after by the business to help shape strategy and inform intent.”

The TEAM had done great.  They had knocked everything thrown their way out of the park.  They were having fun and everyone wanted them.  Then it hit me.  They did it!  They were a self-managing, self-organizing, high-performing machine.  That’s what is supposed to happen.

 

 

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.

You can’t part time a new team…

Recently, there was a suggestion made that a Scrum Master need only dedicate 25% of his time to a team.  I disagree.  I really, really disagree.  Even if the team members are experienced Agile team members, there’s forming that needs to happen and they need to find their groove.  If they’re not experienced Agile team members, then 25% certainly won’t cut it.

MAYBE when a team has been together and is in that high-performing place, a Scrum Master need only devote 25% of their time but, I still question it.

So, tell me, what do you think?

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