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.

Advertisements

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.

If you measure to a minimum, guess what you’ll get…

The minimum.  If you wanted the minimum, then, congratulations!  I’m pretty sure people don’t strive for the minimum though so what should be measured  instead?  Measure progress against the end goal.  I know.  I know.  It’s crazy talk but, seriously, if there’s a goal you want to hit why not try to assess yourself against it?  I guess the argument of “we want to know where we are against the least acceptable  metric” may hold some water.  However, I don’t want something that tells me 100% meet the minimum.  I would MUCH rather know that 8% meet the target and 70% are pretty damn close.  Those who are meeting the minimum now have a little competition and may actually kick it into high gear.

If I know who is closest to the target, I have a chance to leverage their insights and help those who are anywhere close get closer.  I can see what everyone has in common (who isn’t excelling) and work towards identifying a root cause to help make it easier for them to hit the target.  If 100% are meeting the minimum, what does that tell me?  What can I do with that information? Reward it?  Um……

I know!  Let’s set an interim target!  Guess what you’ll get?  100% are meeting the interim target.  And it all starts again.  Seriously, folks, let’s strive to meet the goal.  Let’s not sell ourselves short and give ourselves crutches.  People want to do well and if well means the minimum, that’s what you’ll get.

Personally, I love a challenge.  When I’m not challenged, I get lazy.  When you expect greatness from people you will get greatness.  When you expect mediocrity you will get mediocrity.  Shoot for the stars people!!  Then, when you have scooped them all up, shoot for another galaxy.  I DARE YOU TO BE BETTER THAN YOU ALREADY ARE!

Three things to keep in mind for new teams

My very first team as a “Scrum Master” (having never taken a class or worked in Agile before – thus the quotes) wasn’t formed well and I’m pretty sure none of us knew what the heck we were doing Agile-wise.  At least I didn’t.  That said there is one thing I did with that team which I still do today.  I protected them.  Protection is important for teams and it’s not just the job of a Scrum Master to do it.  When I say protect, I think, what I mean is to protect the environment.  A team needs an environment where they can be honest without repercussions, feel comfortable holding each other accountable, disagree on how to reach common objective, focus on themselves and their commitment and work in a way that works for them.  I’ll never forget the Product Owner coming over to me and whispering that a developer was watching TV in the galley while eating lunch.  The Product Owner thought the poor guy should be in the room coding!  It wasn’t enough that the team and this particular developer had been killing themselves for weeks – they needed to starve too.  Obviously, that wasn’t OK and I said as much to the PO (bless his heart).  As a Scrum Master, you need to care for and about the people on your team and help protect the integrity of their environment.   Amr Elssamadisy’s blog    has some great posts on the importance of a safe environment which are worthy of your time and thought.   Protect the team!

Further along my Agile journey, I noticed some teams had working agreements that took up an entire wall.  Well, not an ENTIRE wall but, almost.  On my teams, the “norms” were always super simple and I don’t think I’ve seen more than 8 in any of them.  My teams would have things like “If you’re sick, stay home.” and “Don’t eat smelly food in the room.”.  I saw one team that had Team Norms, Meeting Norms, Stand Up Norms and Core Hour Norms.  It was nuts.  It seemed, to me, that the norms were representative of many individuals protecting what they wanted.  Their agreements didn’t reflect a single entity at all.  Maybe I’m crazy but, I believe Norms should be simple, things everyone can agree on and no more than 10 bullet points.  Keep it simple!

Further still….I created a backlog for newly forming teams.  The stories accounted for things teams need to do when they first form like agree on a team name, create a team vision, decide how to organize the board, inventory their skill sets, establish team norms and so on.  Each story had acceptance criteria.  I let the team prioritize them and they also estimated them.  A sprint was equal to 2 hours and they used the complete Scrum Process.  The first time I did this was really, really cool.  The team went out, as a team, to scout out other rooms and interview other teams to get ideas.  They didn’t split up and what they got out of it was SYNERGY.  Everything in that room had their stamp on it and it was clear to anyone who walked in.  Seriously, executives would comment on how good the energy was in that room.  My only role in that whole exercise was to answer questions as they related to Scrum and keep it simple for them.  So, to sum up, let the team own the team from day 1.

I heard a Scrum Master refer to himself as a babysitter the other day and it made me cringe.  The truly horrible part was he was saying it to a class of team members who were learning about Agile.  *sigh*  The beginning time for a team is precious.  There’s no history or baggage.  There’s a great clean slate and anything is possible.  This is time to take advantage of to team build, establish ownership (the team owns the team) and set the tone for duration of their existence.  As a Scrum Master, don’t squander this time and don’t let anyone take it away from the team either.  Protect their space to form.  You’re not a babysitter or a hammer.   People are smart.  They want to do well and they will give their best IF they have an environment to enable them and a Scrum Master who is willing to protect them, keep it simple and let the team own the team.

Middle Managers are like Addicts…

This weeks experiment for softwehr and I is to write about Middle Managers.  This topic generates a LOT of good discussion.  In fact, I’ve already talked about it here.  I’m actively experimenting with this group daily, using Dan Mezick’s book: The Culture Game, trying to find some keys.  I’ll tell you up front I’m failing a lot.  My failure (I like to call it learning) is due in large part to the fact I’m trying to instill some new habits and responses that aren’t instinctive yet.

What is it I’m trying to do?  I’m trying to get people in the middle layer to change the way they view and execute work.  This group is tough.  What’s the value proposition for them?  It’s easy for teams: you will be empowered and valued for the skills and creativity you bring.  For Executives, you are going see more value being delivered, a reduction in defects and operational costs, improvement in associate morale and MORE revenue!  What’s not to love right?  For Middle Managers….you guys get to???  So, here’s what I am trying so far:

  1. Everyone has a choice to opt in or out.  I am focusing on those who are opting in. Normally, I focus on the other set thinking that’s where the problem is.  It isn’t.   There is absolutely nothing to be gained by trying to convince them.  By focusing on those who are opting in, I am creating viruses.
  2. I am asking if the purpose I believe we are striving for is aligned with their thinking.  Aligning to a common goal/purpose is essential.  Often, we are not.  However, I have found that stating my “own” purpose gets them thinking AND I find some converts.  How do I know this?  The converts refer back to it throughout the meeting and ask me questions following the meeting to understand what I was trying to get at.  They want to learn.  Virus created.
  3. I am taking every possible opportunity to teach…what are elements of high-performing teams, why is the environment essential and all kinds of other interesting systemic cultural impediments.  Sometimes, I’ll get a polite nod and murmur other times, I see a laser-like focus appear in their eyes and they ask “What are we doing to solve that?”.  HA!  Got ya.  I now have a virus AND someone to go and tackle the impediment.
  4. Every day I set out to do something “brave”.  Sometimes, the brave thing is any ONE of the items above.  Other times, it’s bolder.  The worst thing that happens?  I fail/learn.

Notice there’s nothing on here I’m forcing on anyone.  Middle managers are like addicts.  They have to recognize and accept their problem before they seek treatment.  My role isn’t to treat them.  It’s to help them be aware and find their value proposition in this change.  I help them be aware by doing the things above and some more. Eventually, more people attain awareness and results WILL follow (I have to have faith here).  Those who haven’t yet experienced it start asking those who have “How did you do that?” and the virus spreads.

The middle layer can make or break your transformation.  It’s a constituency we must pay attention to.  They’re the most difficult ones to reach.  They are afraid.  Seriously, download Dan’s book on your Kindle and read it a couple times.  As you’re reading start trying.  You have to start small to make it big.  Just like a virus.

Frameworks are full of….

People.

A process doesn’t work without people.  A framework doesn’t work without people.  Process and frameworks are meant to facilitate the delivery of value.  Value isn’t delivered unless you have people.  If everyone can agree on this we should also be able to agree that, in order for the implementation of a new framework, process or effort to deliver value to customers faster, people are THE lynchpin.

If we agree people are the lynchpin, we need to agree on what they need to be a strong lynchpin.  If I think on times where I have performed the best, there were common themes:

  1. I trusted those I was working with and was trusted by those I was working for
  2. The people I was working with were all focused on the same goal
  3. We all had high standards for ourselves, our product and each other
  4. Having FUN was not an afterthought

There are a few more but, these are the “biggies”.  Note, there is nothing in here about how we worked together.  I say this because I think, sometimes, it’s easy to get caught up in the process – or framework – of work.  Actually, the simpler the framework, the harder it is to implement because it is so very reliant on…people.  When you look at Scrum, it’s very light on the process and how.  Kanban is even lighter.  Simple processes imply a faith and trust in people to do the best they can, be open and honest with themselves and each other and try to be better each time.

Heavy processes or frameworks imply a lack of trust in people.  Otherwise…why all the process?  Process is made of checkpoints, flows, owners, approvers, accountable, responsible and the list goes on and on.  At the end of the day, people either did what they set out to do or they didn’t.  A process or framework won’t actually guarantee success.

People will.

When a company or team decides to implement a new framework, they need to first look at the people and decide a few things.  One, do they have people they trust?  Two, are they (the people making the decision) open to working differently?  Three, do they believe the framework they are implementing and the people they have to work within it will truly help us achieve their goal?

Processes and frameworks for the sake of having them are no good.  It’s not good for the company, the people or the customers.  Make sure there’s an environment for people to be successful in.  Keep the framework/process as light as possible and.  Ensure people are working on valuable products.  Leave the people alone unless they tell you they need you.  Then, be supportive and enable their learning and success.

Knowing and Understanding is different than Applying and Learning

As I intimated in a previous post, when I first heard about Agile and Scrum, I poked around a bit and came to the conclusion it wasn’t very different from what I was already doing.  I figured it was no different than normal Project Management except I would have a captive project team (YAY!), all the work going on would be on a board instead of .mpp (EVEN LOUDER YAY!) and there would be 1 fifteen minute daily meeting rather than all the other endless meetings.  Yeaaaahhhhhh.  So, that wasn’t right.

I found some people in the department who did know this and started learning from them.  When I say started learning I started accumulating knowledge.  After I spent a good amount of time listening to others, there were pieces that started to click.  I still didn’t have the whole picture partly because I was getting information in pieces and partly because I didn’t “get” it and, as a PM, didn’t believe what I was hearing really either.

As more and more pieces started to fall into place I began to understand.  That is I knew, in theory, what I should expect and what Scrum should look like.  Once I reached a level of understanding, I was able to ask much better questions AND accumulate more information.  If you thought I was going to say I could apply it (well), I’m sorry to have let you down. I did start looking at the the team, the organization and myself a little differently and tried to think about how all of this information could possibly be applied.  My attempts had not been very, well, awesome.  I had theories…

I set out to figure out HOW to effectively apply my understanding of the information I knew.  Do you know what???  It’s really difficult to tell someone HOW to apply the information they have.  People can give you suggestions and they will be good ones.  True Learning happens when you just go and start trying it out.  We tell teams to do it right?  Fail fast (which means learn fast to me).

Talk about scary.  It’s scary to be with a team and just try stuff out.  However try you MUST.  You will learn so much faster and you can apply all that learning to grow and get even better.  You need courage, trust, some more courage and a desire to improve.  Knowing is useless unless you’re learning, applying and learning some more.  If I had started trying to apply all that knowledge earlier, I would have learned faster.  Would there have been mistakes?  Yes.  What do we learn the most from?  Our mistakes.  See where I’m going here?

When people say “I know all about Agile and Scrum.”  Just smile and wave and wait.  In the meantime, get out there and experiment.  Don’t be afraid to learn and grow.

Working in Agile May Seem Risky at First….

The very first project I worked on in IT was “Agile”.  As a new-to-IT project manager (my background was in Business Strategy and Operations) I wasn’t quite sure what this meant so I poked around, did a little research and came to the (very wrong) conclusion that it was no different than what I was doing today… Except now everything the team was working on would be on a board and we would only have to a have a 15 minute meeting everyday to discuss it.  Bless my heart.

For many reasons, the project was NOT Agile.  The team worked an insane amount of overtime with requirements and NFRs changing at a break-neck pace.  Two weeks before launch everything was ready.  It was defect free (as far as we knew), environments were working (as far as we knew), the performance testing was successful (as far as we knew) and we were only waiting for “Go Live”.  About a week or so before launch the Business Customer walked into the room, congratulated the team on a job well done (10 months) and let us know we would not be launching into production.  Why?  The financial collapse happened and the products that would be offered would not be available to customers any longer.  The company could not take the risk.

This is one story I use to demonstrate the risk reducing benefits of Agile.  Had the team been running Agile, truly Agile, we would not  launch EVERYTHING into production on one day. We also wouldn’t have wasted – yes wasted – money for new Infrastructure, resources and consulting.  We would not, at the end of the project, only have a “good job” to show for all the team had accomplished.

  • Small, incremental releases would have told us environments were working as expected and minimized the risk of identifying problems too late
  • The developers, who had very different styles and approaches, would have HAD to align on working agreements and standards to ensure smaller releases would be successful and easier to maintain and build on.  I shudder to think of how challenging the application would have been to manage…
  • The business could have tested whether or not they could drive customers to the application, if it was useful to the customers, WHAT the customers really wanted and make informed decisions regarding their investment and their strategy.
  • The team could have worked in a thoughtful, sustainable way rather than the reactive death march way they were forced to operate in making for a happier team and, ultimately, a more productive team.
  • The application may have not been kept alive following the collapse but, the learning would have been there.  There would have been SOME value to the business and the customers generated.

Really, the list can go on and on.  Working in an Agile environment is less risky.  The business strategy is focused on delivering value.  If something isn’t valuable to the end-user, you know it quickly – not after months or sometimes years. This means the business isn’t wasting money and resources on non-value add efforts.  The team is able to respond to quickly to change.  If direction shifts following a sprint, the overall impact is limited to one sprints worth of effort.  Think about it.  When there’s a scope change 10 months into a 12 month project in waterfall, the ripple effects can be tremendous.  That’s no good for anyone.  Your architects and support can work ahead just in time rather than having to anticipate every need for the next couple years saving money and effort.  Who wants to build something that may or may not be needed?  When you release something into production that does cause a problem you’re not searching through a massive code base that took months/years to develop.  You can focus on two weeks worth, identify the problem quickly and limit the impact to your customers and the platform.  When you make small changes and something is really awesome you can build on that to maximize the value rather than focusing on other things that may not.  An organization can respond to necessary changes that will help to reduce call center volume which has exploded since some marketing or servicing change was introduced reducing the risk of attrition for both customers and the poor call center employees.

There’s another meaningful way in which Agile reduces risk.  People.  Employees are working on things which they know and believe to be value add to the company and their customers.  They’re empowered. They have business context.  They have support to resolve issues quickly.  They’re happy.  This means they will stick around!  You don’t have a staff of knowledgeable, hard-working and willing resources walking out the door b/c they’re micro-managed, overworked or putting an effort against something that may or may not, at the end of the day, make a difference.

Agile principles have people at their core.  When you focus on people, great things can happen.  When you focus only on the work….

You complete that sentence.  Thanks for reading!

What do you mean I’m not in control?!?

I haven’t been a Scrum Master for a terribly long time, but when I went to my CSM class and my instructor talked about protecting the team I felt like I had come home.  Protecting the team makes sense to me.  What made no sense whatsoever was that the team would be self-managing, self-organizing and standard PM things like, status meetings, budget reports and the like, wouldn’t be necessary. Those were some of  the things I performed to add value.  When people would look back to see how well the project was managed, I could show them all these things and they would know I did a good job.

The team decides how.  Scope creep (aka: change) is welcome.  The team decides what they will work on.  The team decides how they will work together.  THE TEAM!

What do I do?  What do I decide?  What do I manage?

This is what was hard to wrap my head around.  And, I have….mostly.  I have made and will continue to make mistakes.  I definitely prefer being measured by how well the teams I work with perform over whether or not tasks were all completed on time or how awesome my status reports were.  Teams who really embrace Agile do too.

What is hard for you in the transition from Project Manager to Scrum Master?