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.

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.

All Pain and No Gain

In an Agile transformation we all focus on getting the teams set up, training them and get them working in Scrum (or whatever).  Then, you have these teams going and you see some improvement but maybe not the BIG BANG improvement  you thought you would see.  So, you start looking into what the teams are doing.

Are they having stand up? – CHECK!

Are they doing Sprint Planning? – CHECK!

Are they having Retros? – CHECK!

Are they using a Scrum board and burning down daily? – CHECK!

Is it effective? – Ummmmmmmmm

The thing is, the tactical parts of Scrum are in place to teach the teams how to think and work differently.  A team can only get so far with the tactical elements alone.  In order to realize the benefits of Agile, a team needs to shift their mind set and so the all the people outside of the teams.  The tactical part of Agile is easy.  It’s the Cultural part that’s really difficult.

If teams are having challenges breaking down the work into small enough increments, you may be able to address it with some training and hands on guidance during planning.  However, if the business cannot think differently and insists or MORE it may be that the team isn’t empowered to break it down smaller.  Or, maybe, in demo, stakeholders are critical of the “little” the team has ready and pressures for MORE.

If teams aren’t continuously improving and having their retros, it could be that the team needs some instruction/coaching on what continuous improvement means.  Maybe the Scrum Master isn’t leading effective retros and needs some help there.  Or, maybe, the team isn’t given the time for retros because of some outside forces insisting they do something differently.  Maybe the Scrum Master doesn’t have time to learn how to be a Scrum Master because they’re busy writing status reports, going to status meetings and completing documentation for an organization that hasn’t embraced Agile yet and relies on Project Management artifacts and methods.

I’m staring to think an Organizations transformation doesn’t start with teams at all.  I think it starts with everyone else.  Scrum and Agile are easily applied to any type of work.  The Agile values and principles are also applicable to any type of work.  Maybe the teams should be left alone until everyone else understands how to work in this way.  In focusing the effort outside teams first, the culture shift could start with those who have the ability to stifle or supercharge the teams.  Once everyone outside the teams are ready for the teams THEN the transformation can begin.

Because, until the culture starts changing – in earnest – an organization is really just going through the motions NOT transforming.

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.

Burning Down Not Out


Burndown
The burn down.   If you haven’t used one for your project before, the concept is easy.  Given a lot of something now, how long will it take to get rid of it all.  Work, hours, tasks, budget allocation, release features…  Agile also had the concept of a burn up…  instead of going to zero we simply flip it so that we will accumulate work over time up to a maximum level of something.  Preference was up to the organization, but sometimes both were kept as a way to instantly recognize what level/scale was referred to.  If one was talking about the progress of a team (burn down) or the progress of a release (burn up).  So much of what we do is empirical.  In other words; it is an observed side-effect of our direct efforts. At times this may not be intuitive.  Scrum uses these charts to point our attention to when is done?  It is not an artificial moment in time that is the focus.  It is our software deliverable we really focus on.  The accumulation/dispersion of effort through consistent units of time is represented in a way which helps us characterize if our capacity for this work is realistic.  By knowing our capacity, we are also dedicated in continuously improving the organization’s ability to do work.  We do all of this through great teams.

A Team Burn down  Scale the y axis in hours, tasks, story points and the unit of choice can affect how the team works.  As a scrum master there are some tools which enable the tracking of hours, and tasks and will display both of these for a team simultaneously.  Typically the lines will track each other very similarly though different in scale.  It is a matter of resolution.  350 hours seems to be a finer resolution than 70 tasks, but what if the team enters updates just every evening?  The maturity of the team also comes into play here.  A shu (Shu – new, Ha – intermediate,  Ri – advanced) team, just coming together may find it easier to talk in hours the first few sprints.  As they get better, and need to look up across the sprint.  A bootstrap out of hours and simply into done tasks is usually better. It is a matter of what I will call transaction distraction.  A better term might even be ‘clutter’.  So many things to put a fine point upon that we sometimes lose sight of the middle and end games. Another way to view it is a ‘level up’ as we master some things and begin to practice a higher level of awareness for things of greater scale.   Some teams prefer to retain the hours perspective as a sanity check when planning the next sprint.  It is another lens through which to assess the risk of the work they are forecasting and committing to.  I will use a task burn down and usually focus a ha team on it when we see some risk to the sprint.  Would a ri team even need tasks?  Perhaps the story pointing may be an accurate enough guide for these experienced veterans. A task-level burn down might consider the following:

  • Tasking. Using the task board, establishes a plan. This is the wall or whiteboard around which the team can hold their daily scrum.  I even had a ‘land locked’ team show creativity and wrap theirs around a column in the middle of their pod!  The teams work this plan and adjust the plan daily.  Visible, active, shared problem solving and swarming.  Many coaches like to say Hold Accountable and there is something to this… I prefer to give it a twist though and say Help Accountable.  Not everyone is good at seeing when they are being distracted, stopped by some problem, or simply need help.  Are we getting better as we get accustom to the interaction or even the technology?    Tasks that come anchored with someone’s hour limit – doesn’t prevent, but can erode the swarming behavior we want to see in our teams.  Especially if the estimate is made from a different skill level.  We are not trading hours equally – but if you grab this task we are at a higher level of trust that one of us has the ball and will run with it.
  • Transactional duplication.  There is overhead or a cost to the number of things we track, the tools we use to fill out certain forms.  If instead there was a very simple rule – that would eliminate just some of our effort… we move that much faster.  If we are at a sustainable pace – aren’t we agreeing to average a 40 hour week?  Do we need to track the hours of every task?… probably not.  Also know that most rules have exceptions.  On the whole, however, we are trying to work at a predictable pace where people won’t burn out.  They also need some time to be able improve processes, tools, and even themselves.
  • Characterize.  This is for the team… I would not show a team burn down in a review… maybe an occasional retrospective though. A team can get desensitized by being shown it every day.  Are you looking deeper though?  A scrum master, at times, is sort of  a team historian.  Would you know the most stories or most tasks we ever took on in a sprint and completed?… these small benchmarks can help to identify when the team has improved, and have an excuse to celebrate a broken record.  For instance – I keep track what the MOST TASKS the team ever completed in one day as a team record. It is a RATE – which does depend on the work.  We assume the work will always change.   How about the average number of task closures per day?  It is to identify risk. How well do they task out stories?  The team will help accept and relay confidence or mitigate and problem solve to bring the sprint in successfully.  It is a reality check against how our team performs.  We ask this of ourselves so that we can characterize the engine, the team, and the severity of the situation.  We want to inform the product owner and the program as soon as possible.
  • Focus.  A scrum master directs the focus of the team.  Remember transaction distraction, there is only so many things we can hold in our attention.   Is it really about the hours, getting the tasks to done, getting the story completed, the sprint goal being achieved, or the working software?  At different times, for different circumstances, it could actually be any of these.  What was the price in order to get there in terms of impact?  We use the burn down to be thought’full’.  To alert ourselves to a severity and to address it calmly in the best manner that suggests itself.  The burn down is a side effect of our work, not a focus.   In other words our work is not done just to satisfy the burn down. It is too easily gamed. No one will yank agile badges here, but we use it with the intent to become better problem solvers.  We want to be able to pull our heads up out of activity every so often to assess the situation critically, be creative, and improve a few things while delivering the software.

A Release burn down

The term ‘Characterize’ is a good one to replicate here as well.  It is the way with which we are assessing the organization’s ability to  deliver work. How well can we share this load across all teams for the most important priorities.  What trade-offs do we have to make for our potentially shippable increment.  This helps us tie everything together at a larger level.  Are we even honest with ourselves for what is complete?  What it doesn’t show may be even more important:  things like dependencies and risks. A burn down is just a tool.  It can be like any tool; useful, misused, or dismissed.

Focus on those who OPT IN

I’ve been thinking a lot lately on where to focus.  In a large transformation effort, there’s more than one area requiring attention:  Teams, Scrum Masters, Middle Management, Leadership, Performance Management, Space, Culture…..  You name it, it probably needs some care and feeding so, where’s a person supposed to spend time?

Initially, my thought was to focus on those people or places that were not far along the change curve.  Then, I realized how much effort and time went into that category.  We talk about empowering people and teams to deliver value.  Why shouldn’t the same apply to learning and change?  If you make training, workshops, blogs, books, coaches and every possible thing imaginable available, people who want to learn and change will avail themselves of those resources and more.

The time we spend “selling”, convincing, cajoling and, yes, begging people to give it a try is wasted.  Those people will either opt in or not.  I’m not saying zero time should be spent on this category.  I AM saying it’s a pull system and, when asked or requested, some time should be spent there.  Spending time pushing it isn’t valuable. As people are ready, they will pull – just like a team and a backlog.

Focusing on those who are opting in makes sense.  Results will happen.  People will be happier.  Formerly opt-out people will notice and they will come.  When they’re ready, you should be too.  Be ready to help, coach, guide and keep the road as clear as possible for their own transformation journey.  The cycle will continue.  It just takes time.

Commit and don’t look back

We talk a great deal about commitment in Agile.  Generally, in IT, we’re afraid to commit.  When you commit it could mean you put yourself and your team on a death march.  There’s no such thing as a guarantee or sure thing but, there is such a thing as commitment.

Commitment means you will give your all.  Your absolute best.  You will do this for your team and yourself because you take your word seriously AND you want to give and be your best.  Beyond yourself, you will commit to always learn and improve.  You commit to holding yourself and your team mates accountable.  You commit to succeed and fail as a team – one entity.

Really, it’s no different than life. Personally, I have had to make tough decisions based on whether or not I felt I would be able to give my best and commit.  The times I have not listened to myself, I have found myself to not be “all in” and it hasn’t been a great experience.

To commit, you need to have heart and passion.  It has to be about more than you.  It can be intimidating but, it’s so worth it.

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.