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.

Scrum Master Series: Team Maturity

There is no doubt that a scrum master’s role is seen as a leader.  A leader should also be prepared to adjust their leadership style to provide what the group may be missing.  This would compliment the team.  Other times the team might be best served by capitalizing on their strengths and instead augment them.  Yes, there may also be times when the team is so empowered that for a short while they may be almost invisible; sharing the leadership with others. A scrum master might consider being lenient with some processes in the cases where the team is showing respect for the agile principals.

A Scrum master will grow a team.  Keep the team and the organization continuously improving.  The ability to identify where a team is in its maturity will help.  To be clear, a team’s maturity has little to do with the time spent together and is more about the characteristics of the team.  How do they interact?  How well do they tackle some fairly thought-intensive work?

Bruce Tuckman described 5 phases to team formation.  All these phases required common tasks or goals for the team to align with. While the product owner’s abilities lay in the analysis of unfolding information; the scrum master’s job is to facilitate the team’s transition through towards becoming more mature, shaping the interaction.

Forming:

Here the scrum master is a trainer.  This group of individuals may be seeking acceptance and may feel relatively uninformed.  Being more directive while members of the team seek acceptance and start orienting themselves.

Storming:

Still as a trainer, the team may be expressing some dissatisfaction as they test limits and boundaries.  Many different ideas are competing as they form acceptable leadership behaviors.  How the team deals with conflict will stop them or help them move onward.  Does the team focus on minutia or avoid real issues?  How is time spent?

Norming

Now as a coach, the scrum master is helping the team integrate with one another. The team has a goal and a mutually derived plan.  Some of the team members may have to acknowledge and help champion an idea that was someone else’s or perhaps even contrary to their own. All done towards achieving the group goal.

Performing

Now as a Mentor, the scrum master is seeing the team produce.  The team has a rhythm and perhaps even a swagger as they operate smoothly and are able to problem solve effectively without much conflict.  There is a high trust among the team members.

Adjournment

Things with beginnings also have an end.  Having closure, ending, celebration, recognition and reflection are all part of this cycle.  If the team delivered, celebrate and recognize the team for the win!  Not every ending is ideal however.  Say that a team has worked 6 months to deliver a product, has a sustainable pace AND met their deadline but the product is never put to market by the company.  There is no closure to the goals that have been the vision of the team for so long.  Motivation will certainly be affected.  It might take a while to get going again.  So too the loss of a team member… even one lost to promotion.  Keep visibility and an openness as teams deliver or maybe even wind down projects, deprecate portfolios, and assign applications to obsolescence.

Being an eternal peacemaker within the team might even inhibit a team advancing from norming to performing.  The largest caveat here is that the journey is not always a linear one.  The team can revert or be thrown into ANY of the stages for a time.  Maybe a new member has been added, or a particular stressor has the team acting differently.

Another way to look at a team’s maturity is to gauge the capability and characteristics.  Every team has it’s own unique identity, and watching an agile team work is  organizational behavior.

12 Criteria for measuring the maturity of a team

  • Feedback Mechanisms (poor -> excellent)  Does the team adapt? How long does it take to adjust?  Does it revert to a defensive posture when questioned or is it more reflective and thoughtfull? Does the team possess and agile mindset where they exhibit iterative, time-boxed and incremental improvement?
  • Decision Making Methods (dysfunctional -> functional)  This is bad when a head is locked up in a little view or single perspective.
  • Group Loyalty / Cohesion (low -> high)
  • Processes and Tools (inflexible ->very flexible)
  • Use of Member resources (poor -> excellent) Does the team exhibit swarming behavior? Is everyone efficient and effective?  Are we challenged and utilized?
  • Communications (unclear -> clear)  Does the team talk? Can I hear them? Does the team participate and help inform the organization? Are they visible with information radiators that are up to date and aligned?
  • Goals (unclear -> clear) The Product Owner will answer what is next, while the team will be able to explain their vision, how we will get there, and how we will know if we are there yet.
  • Problem-Solving Ability (simple -> complex)  Does the team stall out when presented with a challenge or do they forge ahead?  Are the solutions brittle or robust?
  • Participation in Leadership (low -> high) Is the team engaging, challenging and growing the organization around them.  Great teams have and influence others and benefit those around them.  What about outside the organization and in the community?
  • Acceptance of minority views (low -> high) are the quiet ones considered or even invited to speak?  Is is just one person’s opinion again and again? What about all the different perspectives that might use or even abuse this product?
  • Standards (low -> high) Is the quality of work high?  Are there defects or rework that make others avoid this team?  Is this team’s work readily accepted and meet a definition of done that sets a new level of expectation.

Just remember that where your team(s) might be,– is just the start of where they might go.

Scrum Master Series: The Team

Definitions and Back to Basics

Once in awhile I get to look back over some of the notes I put together on topics.    I think about organizations, teams and roles that we have.  Once in a while I have to lay the justification to an organization for one of the roles.  A scrum master included.  For a few people in the organization, as I take them through their valley of disbelief, I like to start very simply, and sometime include some history lessons along the way.  Dr. Winston Rice, the father of waterfall wasn’t all bad, but over time we learned to organize ourselves in even better ways.  New ideas in an organization that is pretty big and set in its ways is never easy, but I love watching the transformation.  I have the patience to see the changes and continue to grow and support the people who are experiencing it as well.

I had a developer say to me that they hated agile.  A very clear and aggressive message with an emotional anchor.  All pre-formed before I even got to know this individual or what his prior experiences were.  I love what I do, and it shows.

It’s not about you.

Organizations are dedicated to using teams.  This means what?   A team is a group of people… pretty basic.  But wait, there is more!

  • Holding themselves collectively accountable
  • For using complimentary skills
  • To achieve a common purpose

Scrum does not assume a minimal skill set.  There is also an assumption that the work is complex enough to warrant a team. Ralph Douglas Stacey who spent a career analyzing organizational relationships had a Matrix which might be adapted to agile as follows…Stacey Matrix

Scrum tends to play really well in breaking things up from chaos and pulling them down into the complex realm, and again pulling complex solutions down into the complicated.  Scrum for it’s simplicity cuts through the noise.  Kanban tends to work really well with simple or repetitive solutions we find ourselves performing again and again.solutions down into the complicated.

Why a team?

Well, it has the tendency to be good for people.

  • Improves our creativity
  • Can make better decisions
  • Can increase commitments to action
  • Help control their members
  • Helps offset large organization sizes
  • Types
    • Formal vs Informal
    • Temporary vs Long Term

In groups of a certain size we no longer feel lost amidst a very large organization.  Daniel Goleman who wrote Social Intelligence was curious about the maximum number of people to exhibit innovation in groups.  What he saw was natural pairing in groups of 2 then 4 and somewhere greater than 8 the groups tended to fracture and not be as cohesive.  Greater than 8 we don’t collaborate as well.  Seems right in line with what individual scrum teams are used to.

What can Teams Do?

It does seems obvious that we use them to develop software.  Our teams place an emphasis on making or doing things.  Team might also exist to recommend or just run things as well.   I get into teams more and more in the coming weeks as this is really where the scrum master matters most.  The team might be considered the scrum master’s product.

I will end with some immediate Dangers to a team.  Again this is always tricky with people who can have selective hearing. As a basis for evaluation in order to really make decisions with steps towards getting better, there are several terms which apply to groups becoming dysfunctional.

Dangers to a Team:

  • Social Loafing – complacency.  It is GREAT to have fun (There is an awful lots of stress and hard work)  but this points more to appropriateness within the context of accomplishment
  • Group think – the team actually loses its ability to think critically and is making decision from a defensive posture within the organizational hierarchy.
  • Social Facilitation – behaviors that start to become acceptable in front of others.  Teasing and hazing are such examples.
  • Personality Conflicts
    • Antagonizing relationships
    • jeopardize team accomplishments
  • Disruptive Behavior
    • Interrupts the group’s processes
    • Limits the teams effectiveness
    • Impacts the team’s cohesiveness

I have never called out an individual as being an impediment, as I tend to distinguish and separate behavior from a person.  There are certainly some behaviors I don’t care for and wont be helpful to a team.  One of the ways to focus on the good part of being within a team is to call out your working agreements.  Together as a team establish some guiding principles of your own.  There are quite a few examples and it has the tendency to put everyone on the same foot forward as they will come together against some tough thought problems.

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

Respectfully Real

Dilbert Drama Queen

Respect for the Individual is a part of my company’s culture and a huge part of my personal belief structure. When I was a kid and would get in a fight with my siblings my parents usually took the “stop your fighting now; kiss and make up” approach. So, as I grew up and entered High School, University, and the workforce, that was the approach I would most often take; if I saw conflict arise I would encourage the parties involved to stop fighting and “kiss and make up”, as it were. What I’ve come to understand as a Scrum Master and Agile Coach is that conflict is not always a bad thing. In fact, in order for self-organized teams to reach their fullest potential, conflict is necessary.

I was first introduced to this concept by Lyssa Adkins and Michael Spayd at the 2012 Scrum Alliance Global Gathering in Atlanta. They were leading a break-out session entitled “Embracing Conflict: A Systems Intelligence Approach to Conflict Facilitation for Scrum Masters, Coaches & Leaders”. There I learned that there is a difference between Productive Conflict and Unproductive Conflict. In essence, Productive Conflict is issue-driven, where the conflict is centered on a disagreement on how to address a given need, whereas Unproductive Conflict is ego-driven. This was a fascinating concept to me at the time – that there exists a type of conflict that is not only okay but should be encouraged! Despite their masterful instruction, I still struggled with this as I naturally shy away from any form of conflict. I’ve gotten better in the year and a half since I heard this message, and would like to share some advice from what I’ve learned.

Ask Why

I have a son who is almost six. He can drive my wife and I crazy with what she refers to as “Whyarrhea”; he asks “Why?” so often that it’s as if he has no control over it. I fear that my colleagues may feel the same way about me! I always want to understand “Why?”. Why did you choose that tool? Why are you producing that metric? Why are you having this meeting? Why are you working so many hours? You get the idea.

People who feel compelled to do things without understanding why they are doing them scare me. So, when I see conflict arise in my team, I start asking “Why?”. I want to get to the root of what they’re arguing about, and I don’t stop asking “Why?” until I get all parties to the same root problem. Once I understand what they’re really arguing about, I get them to explain their contradictory solutions so that we can all weigh the pros and cons of each. Once each solution is explained, I ask what it will take for us to get to a consensus, be it a proof of concept, cost/savings analysis, weighted requirements matrix, etc. I remind them that the solution doesn’t have to be perfect, just good enough.

This approach doesn’t work if the conflict is ego-driven, and this root cause analysis, logical solutions approach will reveal Unproductive Conflict fairly quickly.

Ask the Stupid Questions

I come from a background of software development, but I like to act like I don’t sometimes. If the team seems to be chugging along without any kind of disagreement I may throw a wrench in the system by asking something they might consider being a stupid question. “How are you going to test that?” “Why don’t you do it this way?” “I heard about this Open Source library we could use, why don’t we try that?” These questions are good at introducing Productive Conflict in one of two ways. First, I might strike a chord that resonates with one of the team members who didn’t want to speak up at first, thus bringing out a beneficial conversation that might not have otherwise taken place.

Second, the team members may find that they agree on a decision but not for the same reasons; by trying to answer me, they may find that there is an underlying factor that they disagree on which may impact implementation details or future decisions. Without the “stupid question”, this realization may have occurred much later down the line, if at all. Some may think that not ever revealing a disagreement is a good thing; what they do not realize is that the conversations that those disagreements create and the consensus that results makes the team much better than they would otherwise be. The sooner we can make that happen, the better.

Solicit Ideas prior to Conversation

What is the point of Planning Poker? Most people will tell you that it’s to prevent influencers from running the show when the team is estimating the work, which is definitely one of its major benefits. Without something like Planning Poker, the timid on the team would be left to accept the estimates of the bold, resulting in a lack of ownership and some rather passive-aggressive Retros when commitments are not met.

This concept can and should be extended to other realms as well. Use this when picking a tech stack. Discuss the need first; make sure that everyone understands what the purpose will be behind whatever language, library, or tool they will be picking. Then let everyone bring their solution proposals to the table, with everyone revealing their recommendations at the same time. This gives everyone a voice and produces conversation that might otherwise not have happened.

Separate Ideas from People

Great, high-performing teams embrace Productive Conflict because they don’t associate people with their ideas. All ideas belong to the team, and no person is belittled because their idea was not chosen by the team. This is difficult for many people; it is hard to have your idea rejected without feeling rejected as a person. You can help by referring to ideas by a name or title appropriate for the idea, such as “Spring” or “EJB3”, and not “Bob’s idea” or “Susie’s suggestion”.

You can also reinforce the team’s ownership of ideas by congratulating the entire team for a job well done when ideas are successfully implemented. We succeed or fail as a team, not individuals. If an idea isn’t working out then let’s fail fast and do something different; it does nobody any good to dwell on the fact that the idea was so-and-so’s to begin with. The conversation that led to the decision to implement the idea should have involved everyone and ended with team consensus. That means that, by the end, it was the team’s idea, not one person’s.

Respectfully Real

My CIO, Karenann Terrell, uses the phrase “Respectfully Real” when she wants to discuss something we could be doing better at as a division. She encourages others to voice concerns and even dissent, so long as it’s done respectfully. She understands the power of embracing Productive Conflict. She sees what Lyssa and Michael see – that teams have their own attitudes and behaviors, and that Productive Conflict is an essential tool at improving the team as an entity beyond any of its individual members. Not all conflict is productive and respect for the individual is paramount; however, trying to squash all conflict with a “kiss and make up” approach instead of leveraging it as a tool for growth shows a lack of respect for the team and does them a disservice.

What are your thoughts on conflict? What methods do you use to identify what particular type of conflict is arising? How do you foster an environment that promotes and encourages Productive Conflict? I’d love to get your thoughts. I also hope that I did justice to Lyssa and Michael; if you would like to learn more about taking a Systems approach to Agile Coaching, I suggest you look them up and learn more directly from the source.

A New Comfort Zone

My apologies for not posting on the theme of comfort last week.  Technical difficulties with WordPress stripped my author permissions.  Let me just tell you, that was LOADS of fun.  I’m grateful to Elizabethmiller2 for putting herself and he learning out there for everyone just as I’m grateful to Steve Peha for doing the same.  Thank you, both, very much.  Here’s my very late post on comfort from last week.

Last weeks theme on comfort sent my brain all over the place.  Personally, there are very few periods of my life where I can say I was “comfortable” and I think it’s because I’m wired that way.  When I find myself close to comfortable, invariably, something changes and, more often than not, becomes somewhat UNcomfortable.

Comfortable can mean stable and secure.  There’s a tremendous amount of value in stability and security.  It allows us to do or try things we haven’t before because we KNOW certain things to be true.  It’s important for people to achieve a level of comfort so they can then pursue levels of discomfort.  When you take a look at teams, comfort may mean they’re not challenged – either by their work or themselves.  Don’t get me wrong, we all need time to just breathe, but discomfort for a team probably means they’re challenged.  When a team is challenged, some really amazing behaviors begin to emerge.

Discomfort generally comes hand in hand with change.  The change can be self-inflicted or forced on us.  Change, as we all know, is hard.  A persons or teams ability to perform in uncomfortable situations can be influenced by several things.  The chief influence, in my mind, is their environment.  The environment needs to be safe and what I mean by that is one that is supportive.  Teams experiencing discomfort will have different ways of dealing with it.  Some may engage in some constructive disagreement (loudly).  Others may hole up.  Regardless, teams need to be given the space and support to walk through the change at their pace.

As a Scrum Master, the challenging part is knowing what to do when things are too comfortable, volatile or challenging.  I have to say that I don’t have THE answer.  I have some ideas to try.

TOO COMFORTABLE

  1. Ask the team to think of three things that would be impossible for a team to accomplish in your organization and why it would be awesome if someone could do it.  Get a conversation going – blue sky the heck out of it.  Then, ask them WHY they, amazing team they are, can’t be the ones to try.  The worst that can happen is improvement.
  2. Ask if any team members would be willing to pair with another team member in a different role for a sprint and learn more about the role.  If anyone opts in allow for it in the velocity of the team for that sprint and, in the following one, observe what the results are and call them out to the team.  Then, ask if anyone else would be willing to try.

TOO VOLATILE

  1. Things change fast and furiously and can overwhelm a team.  Get them out of the room.  Go for a walk.  Go for a long lunch.  Give them room to breathe and not think about work for a bit.  A brain break is a good thing.
  2. Have a mind dump exercise.  Ask the team to write everything on their mind on  a piece of paper and, when done, do a quick sort of In their control or NOT in their control.  Then, creatively destroy all those that aren’t in their control and focus on the sprint and save the others for retro data.

TOO CHALLENGING

1. This one is tricky because it’s probably not that it’s too challenging it just seems TOO big.  So, what do we do when things are too big?  Break it down.  Go through an exercise to find the vertical slices with the team and find a simpler picture.  Big challenges are often ones that seem TOO challenging.

2. What?  Is there anything too challenging for your team?  If they have created a vision, bring them back to it and remind them of all the good they have.  Sometimes, you just need someone to believe in you.

Some of the best things I have done in my career have been during times of extreme discomfort.  Admittedly, I have also done some of the worst things during these times too but, those horrible things helped me learn and prepared me for the next one.  So, maybe it’s also good to remind yourself (or your team) about how strong and capable you are.  What’s the worst that can happen?  Even if you fail, you learn and there’s absolutely nothing wrong with that.

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.