That Dang Project Manager Hat

I haven’t been a Project Manager in title for, well, ages.  As a coach or Scrum Master, I should have shed that hat long ago.  And, I did(ish).  The problem is it’s still around and, when things need to GET DONE,  somehow that hat just turns back up….on my head.  Now, the good news is, I realize it and can quickly yank it off and stuff it under my chair but, seriously, I wish it would go away.  It won’t ever go completely away though and I’m still learning how to keep it firmly on the shelf.

So, why did it find its way on my head?  The group I am coaching wants to GET STARTED!  It’s awesome the excitement they all have.  They are eager, after months and months of talking, to get to work.  And, they want to run it Agile and they are leveraging SAFe.  So, before the December productivity vortex hit, we all looked at the calendar and they identified dates for their Quickstart (3 day event for everyone on the release train).  This means, there is a LOT to do.  And, the month of December is pretty much shot so, there’s about 3.5 weeks to get everything accomplished so the train is ready to leave the station.  But, there’s also a Holiday in there AND, most awesome of all, snow storms.  WOOT!

The team of people I am lucky enough to work with right now are amazing.  A massive can-do attitude.  They have overcome illness, broken down cars, two snow storms, children’s illnesses, broken pipes (for 4 people!) and a host of other things way out of their control.  They have all come together, rolled their sleeves up, opened their minds and have focused on getting ready.  They have trained, collaborated, learned, been challenged, formed as a team and had fun.  Honestly, it has been amazing to see and be a part of.  There is absolutely NOTHING this group of people can’t accomplish.  As a coach, this is heaven.  As a PM, I cannot stop thinking about all of the logistics and coordination and organization that needs to happen.  It’s not that there aren’t people working on those things.  They are.  Will it all get done?  Probably.  If something doesn’t get done, will it matter (really matter)?  Probably not.

Coach me:  ALL the right ingredients are there.  The people and the experience are what matters.

PM me:  I need to make certain there are enough post-its, flip charts, sharpies and who is getting red yarn?

Coach me:  These people will adjust.  What matters is their mentality and how they come together through this first event.

PM me:  How can they possibly come together if there aren’t enough sharpies and flip chart markers?!  And, who is printing the hand-outs?  Wait – do we even HAVE a final head count yet?

Coach me:  These guys have it.

PM me:  They have everything except the awesome colored, smelly markers.  They NEED those.

Coach me:  Shut up, PM.

PM me:  Will do – as soon as I have every minute of the day plotted out and accounted for….and confirmation on the sharpies.

So, for all of you former PMs out there who are transitioning to Scrum Master, your PM hat is never really gone.  You just have to recognize when it’s there, on your head, and take it off.  I bet, over the next 8 days, I’ll be taking that sucker off multiple times daily and apologizing to people for continuously asking them if they are certain we will have enough sharpies.

Advertisements

Listen with your eyes…

I find I take far more cues from what I see rather than what I hear.  Long ago, a coach asked me why my communication “style” would change mid-flight and I explained.  When I would see scrunchy faces, raised eyebrows, lip biting or any kind of facial cue I would immediately jump to “I’m doing or saying something wrong”.  The coach encouraged me to ask rather than assume.  I know…it’s a crazy idea.  Honestly, it did seem a little crazy though because the chance was someone would feel as though they were being called out.  It could result in a very uncomfortable situation for that person and for me.  All of that said, we talked about it some more and I said I would give it a try.  I did and have continued to experiment.  Here’s what I have learned to do (so far):

  • Ask for permission.  I let people know I have a tendency to read facial expressions.   Generally I do this by calling out the fact my own face reflects what I’m thinking and I may ask people questions based on what I’m seeing rather than what I’m hearing. I ask if it’s OK for me to do this as well as say it’s perfectly acceptable to tell me it’s not.
  • Determine if it’s appropriate.  When I do see something that makes me want to ask a question or learn more, I think (quickly) if it’s appropriate or not.  For example, if it looks like something isn’t jiving, asking a question is a good thing.  Same thing if it looks like someone doesn’t agree.  Both situations can benefit the larger group with learning or some good discussion and sharing different points of view.  Plus, more than once, I have learned something very, very valuable to apply to the future.  If, on the other hand, someone looks hurt or ticked, I wait and speak to the person individually.
  • Ask with an open mind, heart and sincerity.  It kind of goes like this:  “Bob, I’m seeing a scrunchy face.  I just want to check to see if there’s something you want dig into some more or if I’m not saying something very well.”
  • Allow for an escape route.  The reason I ask a close-ended question is so the person can easily say no and I can easily get back to it.   Also, I ask the question in such a way as whatever is happening is MINE.
  • Thank the person.  I try, really hard, to thank the person for letting me “pick” on them as well for helping make the conversation. training or whatever richer.

This “tool” has been great to get training classes of people who don’t know each other well to open up some more and generate some energy.  It’s also good with teams who  are forming or teams who are having trouble communicating.  I’ve also noticed people in classes and teams will start to do this with each other.  And, they will do it right back to me.  Like I said, what I think is on my face and people will call me out when I have a scrunchy face too.

I’m so grateful to the coach who picked up on this tendency of mine and guided me on how to leverage it over ignoring it.  So much communication happens that can’t be heard.  I mean, how often do we have to filter what we say out of fear of some unintended ramification?  Granted it’s a pretty vulnerable place to be and, if you try this, remember you are putting them there.  Also, if you read this and realize you don’t pay much attention to what you see and rely much more on what you hear, try to observe the team when you’re not in front of them by sticking your headphones in, listening to some music and just watching them.  Jot down what you’re thinking, pull the headphones out and validate with your ears what you heard with your eyes.

An Alternative to the Question: “Why?”

 

It’s something we all do.  We question.  We ask “why”?  However, while a good question, it’s not a question I find to be very helpful.  When I’m asked “why” my thoughts go all over the place.  I’m NOT a linear thinker and I find this question difficult to answer sometimes even though I know the answer.  Actually, I should re-phrase that a bit and say I find it difficult to answer this question in a way that will be easy for the interrogator to understand my thought process and reach a common ground quickly.  It’s a problem.   To make it less of a problem (for me), when people ask me why, I re-phrase  it in my head to ask “What needs to be true”?  I started doing this with others and have been pleased with the outcome.

 

Hopefully, this is something that is useful to you or at least worthy of trying. I use the question “What needs to be true?” in the following scenarios:

 

  • When someone says something isn’t possible.
    • What needs to be true for it to be possible?   
  • When someone says they cannot complete something.
    • What needs to be true in order for you to complete______?
  • When someone says there is a problem.
    • What needs to be true so this will no longer be a problem?
  • When there is a goal or objective that needs to be met.
    • What needs to be true for you to meet this goal/objective?

 

When I ask “What needs to be true?” it shifts the perspective a bit more towards action-oriented versus laundry listing.  It also seems (to me) to be a bit more positive in general.   The problem solving is already beginning.  It’s not the final, end-all or be-all question to be sure but, it’s a more active start.  Here’s how it works in a non-work setting:

 

Statement:  I can’t organize my house.

 

What needs to be true so you can organize your house?

 

  1. I need to have time to dedicate to the task.
  2. I need to have a structure in place that will be easy to maintain.
  3. I need my family to agree to help organize and, then, maintain it.
  4. I need to have less stuff.
  5. I need a place to start.

 

From there, I can dig in a bit more:

 

  1.  How much time do you think you need to start? Where is it in priority to other things you have going on?
  2. How much structure do you need to begin?  What does “easy to maintain” mean to you?
  3. How do you go about getting the family to agree?  What if they won’t or don’t?
  4. How much less stuff?  How will you decide what stuff you need and don’t?
  5. What area of your house drives you the most insane?

 

I also like using this question when I put an idea out there for people to consider and they have a visceral, “That is NOT possible here”, response to it.  Then, they tell me so many things that would need to be true and I can follow up with another one of my favorite questions:   “What are you waiting for”? 

 

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?”

Whipped by WIP?

I bet if you asked any CIO if they would rather release 5 features into production or have 10 efforts in flight they would prefer the former.  Based on my observations, there are way too many decision makers out there who, based on what’s happening in their IT departments, seem to prefer the latter.  When I ask why that is, often, what I hear back is the roadmap was set, the business has their dates and, so, we need to get things started.  Remember, the business strategists are on the hook for ROI so, it would make some sense they would ALSO prefer to deliver 5 features instead of having 10 in flight.  Again, based on what I observe…not so much.  Shockingly, the end result is less delivery, lower quality and a really frustrated group of associates.  Executives are also frustrated by late delivery and lack of completion but, they are unwilling to pull back and limit the WIP.  Their ask?: Work Harder.  My ask?: Stop Starting and Start Finishing!!

To me, the most simple solution is to JUST SAY NO.  This approach doesn’t seem to be an option most places.  The business, the managers and the executives won’t take no for an answer.  Also, it’s not safe to say no.  I mean, really, you’re probably not going to be climbing the ladder if you say no even if it means doing so would yield a better return for all.  Saying no takes a great deal of courage and it’s not fair to put that burden on those who are lower on the totem pole trying to deliver on everything.

One could also PAINT THE PICTURE.  Make a square “plate” out of a piece of paper.  Write everything on a post-it (standard size please.  don’t cheat with the really little ones) you currently have in flight.  Go to your immediate supervisor and have her fill your plate.  Anything that doesn’t fit, doesn’t get worked on.  When something finishes, bring back the stack of post its and fill the space (or NOT!  *gasp*).  I recommend only having room for a maximum of 4 items (and, really, that’s pushing it).  If you’re a manager, ask those who report to you to go through this exercise.  I would bet you will receive their undying gratitude for even caring about it in the first place.

Another means to address it is ROLL UP YOUR SLEEVES.  This is for managers.  I am really suggesting you return to your roots for a bit and pitch in.  Either tackle some of the work yourself to help close things out or, at the very least, de-prioritize anything you have going on to focus instead on serving your team.  Find ways to, at a minimum, make their jobs easier and less frustrating to minimize the impact to morale.

Probably the most impactful would be QUANTIFY THE LOSS.  What would have happened had you closed 10%, 20%, 50% more?  Demonstrate the loss to the bottom line and get the attention of those decision makers!  Other sources of data to pull from may be associate surveys and attrition rates.

It pains me to see people in funks due to the sheer quantity of work in flight.  It’s not a good feeling for anyone to never complete anything.  If you get excited by the fact you were able to respond to 10 e-mails and set up 1 or 2 meetings, it’s a sign.  Take a look around wherever you are and if there’s any applicability to your situation and consider prioritizing how to reduce the frequency and duration of being whipped by WIP.

Taking Away the “Woobie”

Remember when you were little and your mom and dad told you that you have to start doing things on you own? Like using the big girl/big boy potty, or sleeping in your big kid bed by yourself or even the dreaded taking away of the woobie (that means baby blanket)? That’s how I think my Agile team recently felt when I told them that I’m going to move away from the scrum master role and become a coach. They literally looked at me with fear and said “what are we going to do?!?!”

I know what you’re thinking. You’re thinking, “what the heck? A scrum team without a full time scrum master?” Well, I can explain, the team that I have been working with for the past two years is extremely high performing. I honestly feel like I have backed myself out of a job. When a new coaching opportunity came up, I immediately jumped into it, not even thinking that my team would flip out. Why would they? They are so high performing.

I facilitate their ceremonies, but it’s really the team that has become empowered to lead themselves through the stand ups, retros and sprint plannings. When issues arise, they talk about them and compromise to meet in the middle. I honestly sit back sometimes and think “WOW! These guys are awesome!” So again, why would they freak out about something like this? Well, they got scared. It’s just like that feeling when you were little and your parents tell you that it’s time to put away the woobie. It’s not that you can’t do it, it’s just different and you don’t have that comfort blanket sitting right there beside you that you’ve had for a long time. Now, don’t think that I’m calling my team “babies.” They are definitely not babies, but are highly intelligent high performing individuals that I believe can handle this challenge well and become even stronger. I just remember losing my “woobie” and feeling a bit scared.

To ease the pain, I started to back myself out slowly to get them used to the idea. I started out by not attending one of our grooming sessions. The team said “you’re not coming? Who’s going to lead this?” I replied “you are,” and walked out. I wanted the team to feel empowered. To feel like THEY own these ceremonies, not me. I also took it to another level by stepping out of sprint planning for an hour. I didn’t want to go cold Turkey on them for goodness sake, but I definitely implemented a weaning process.  After this I found that they started getting the hang of things on their own and they weren’t coming to me for as many things. They were solving problems on their own. Of course, I was there for any impediments they faced that they couldn’t internally solve, but I really started to see a change in the team.

I recently read an article that talked about what made companies so successful (see below)

http://www.forbes.com/sites/carminegallo/2012/12/11/how-wegmans-apple-store-and-the-ritz-carlton-wins-loyal-customers/

It talks about empowering your associates/team so that they can make decisions and feel like they have some skin in the game. That’s exactly how I wanted my team to feel by me backing out of this role. It’s a great article, so check it out when you have time.

So now I am with my team 50% of the time and I really feel like they have gotten stronger. I almost feel like a parent looking at my children grow up and become adults. They are solving problems on their own, collaborating, communicating and getting work done. It makes me so proud to be a part of this team and I hope to continue to work with them in the future.

Where is Scrum Comfortable?

scrummyWorking with a Scrum team can be many things.  Along a spectrum from Comfortable, to Capable, Challenging, and up to Confused,  Calamitous or maybe Chaotic. I ask of myself where I might be.  Where is the team at?  Always I end up where I can’t blame Scrum, instead I point to something within myself. I will often go one step more towards some actionable improvement.  If there is a feeling of comfortable – is this time to strive for greater contribution?  There are moments of calm and quiet that hit just before storms, in the eye of it, and then afterwards.  So many times I pay attention to the storm that I forget to make use of those times of calm.  Change becomes a pain point instead of a welcome opportunity.  It is also why so many people who see the opportunity in a difficult problem have an easier time with agile.   Is the comfort level that I have derived from consistent cohorts, the familiar type of work in the backlog, my skill level, my contribution, etc.  Comfort too often derives from staying the same.  A much better comfort characteristic indicator, however, is being at ease when these things are changing.  Doesn’t continuous improvement always push us ahead, exploring to the edges of our known comfort map?

Critical thinking is a skill

Constantly this demands we be engaged in the moment.  It cannot emphasize confrontation but rather the ability to be candid. Can we recognize, understand, evaluate, communicate, and in the end have some consensus among ourselves?

Coaching

Be ready to receive.  Even those moments of insight can ever be honed for their delivery.  Inflexibility of consideration often caches impediments and contention.  Am I coach-able and correctable?  Kindergarten taught us to get ready and be open to learn from everywhere.  Are we improving and getting better?  Perhaps, we have been content and things seem to slip and decay just a little bit.  The small slips are covert until they accumulate into a moment of catastrophe and cataclysm.

In the Cards

The product owner often represents the team to the organization.  The work that they are doing is valued, valuable, and visible.  The conversations about this work is captured.  The expectation is convergent and aligned. There is definite commitment by the team. There isn’t any magic concealed in the cards – it is instead within our own character. Our capability as an organization, our capacity as teams, and our collaboration as individuals.

Cooperation

Challenges taken as a team or as a program of teams means that we are trusting others to help attain a very important vision.  That vision is comprised of a great many smaller achievements.  This means no hiding, no distracting, and the correct type of enabling.

The feeling of Safe isn’t the same as comfort.  A safety harness or belt allows us to do things with inherent risk.  We still require preparation and still exercise caution. The safe part allows us to achieve, and excel in a different context, while not falling too far.  A psychological safe space conveys innovation, creativity, and condones some risk towards reward.  Without empowerment, safety, and some closure, change often comes at a high revolutionary cost.

A quiet and calm mind during a storm will help.  I remember one of the first public runs I went on. It was part of a team event and I paired up to run with one of the members.  It was a 10k.  My endurance was starting to ebb.  I remember my mind grasping at the thought that if only my teammate would slow down to make it easier on me.  Anger would not have been far behind.  I knew I had to control the unfair contagion of criticism and instead celebrate their ease of achievement.  I stopped mentally accusing and switched context.  I focused on digging within to examine my own form, gait, and breathing.  It was sloppy and it definitely helped to adjust and self-correct.  The effort allowed me to stay in pace, and finish far faster than I could have on my own.  It is a lesson I carry whenever working with others.  Where do I sense comfort coming from?

Are you having fun?

You know you’re on a good team when you have fun being with your teammates.  To me, having fun at work is critical.  I have worked on really difficult, not-fun projects but had a great time with my team in spite of crummy work.  One team I worked with was in an especially tough spot.  Constant, non-stop change, non-functioning environments and a leadership that didn’t understand the platform or Agile made for some not-at-all fun times.  One day a team member wrote on the board “It’s like we’re trying to change a tire when the car is moving.”.  The next thing you know, people started adding on to it and it went something like this:

It’s like we’re trying to change the tire while the car is moving

And we just found out the spare is flat

And, awesome!, it started to rain

And, there’s no cell reception so calling is not an option

Oh!  There’s a sign:  Next service station 200 miles

And, there hasn’t been a car on the road for the last 3 hours.

Some creative soul put it into pictures and it stayed on the board for a while.  The team was able to poke fun at the situation collectively and, while it didn’t FIX anything it did serve to give a little levity to the situation.  A good team can work well together and be glad to be in the same boat.

Another team I was on would randomly do things like all dress up like another team member or have a “talk like you’re in Marketing” day.   I’ve also seen rotations of telling Chuck Norris jokes at stand up.  Who knew there were so many!  The BEST fun I have seen on a team was when a Team Member plugged her mouse into the developers dock next to her.  He came in, started up and she pretended to be absorbed in her work – headphones on and everything – while making his pointer go crazy.  He rebooted, got going again and, what do you know, the pointer was all over the place.  He then started releasing (for him) expletives.  He immediately shut down AGAIN.  At this point, I dove under my desk b/c I was almost in tears.  I stayed there as he frantically tried to figure out the problem.  He unplugged everything and re-plugged it in.  It was all connected.  He was baffled and getting ready to call support when, finally, the team member rescued him from what was sure to have been a hilarious call.

All of these kinds of interaction go a long way towards team camaraderie or BA.  This is what adds to the soul of a team.  As a Scrum Master, it’s great to hear a team laughing and enjoying being around one another.  It’s part of their hum and single entity identity.  When people are having fun, they like being at work and will engage more.  This only makes for a better end product.  If your team isn’t having fun think of ways to get it going.  Have a happy hour together, start going on walks, look for interactive and engaging (somewhat silly) team exercises, use the Chuck Norris idea.  Ask the team what they would LIKE to do for fun.

I’d love to hear about your teams’ fun.

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.