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.

Unplugged

I’m taking a break from connectivity for a week.  Obviously, I’ll have a phone in case of emergency but, otherwise, I’ll be reading a book (non-work related), having conversations with my family and being lazy.  I’m looking forward to no Internet.  Yep.  I said it.  NO INTERNET.  I leave you with the very capable and zen softwehr.  Have a wonderful week, my friends!

Thoughts on Exiting a Team…

I’m off to a new adventure!  While exciting, it’s also just a little bit nerve-wracking.  What makes leaving one place for another difficult is when you truly love the people you work with and the work you are doing.  I find myself doing quite a bit of individual retrospection on all the people I have been fortunate enough to work with and how they have each influenced me in some way.  I also think about the skills and experiences I want to take with me and how I can improve on them in the future.  Finally, there’s thanking everyone for the opportunity to be a part of their lives and allowing me the opportunity to learn from them and grow.  It’s somewhat sad to be sure but, then, I also think about how my exit really won’t have an impact – in a good way.  The people and work I leave behind will continue on as smoothly as ever.  It’s like water….maybe there’s a little ripple on the surface but still whole and filling up the container just as it should.

It Is What It Is?

Admittedly, I have said this phrase far more than anyone ever should.  And, it’s not a positive phrase either.  It smacks of complacency and disengagement.  It means you KNOW something is wrong and feel powerless to change it or, really, even try.  On one team, I said this phrase so darn much I wrote it on the back of one of those Long John Silvers pirate hats and wore it so I wouldn’t have to say it.   When you hear this phrase, the response should be “Why?”.   When something wrong is so ingrained in the culture that “It is what it is” becomes an acceptable response, it’s time to find out why it is and make it isn’t.  I know that last sentence makes no sense but, I’m certain you get my meaning.  Listen for this phrase and hone in on it.  If nothing else it starts a dialogue about “It” and maybe gets others questioning, searching and, I dunno, solving IT?

An Open Mind is a Terrible Thing To Waste

I was given some really good advice tonight:  In every situation you find yourself in, no matter how many times you have seen it, you must treat it like it’s the first time.  You need to look at it with fresh eyes and try to remember what it was like, for you, the first time. I just loved how that was put.  Once you have gone through the “same” process enough times, it would be easy to become a little numb to all the dynamics in play.  It may also be easy to be a little insensitive to those who are experiencing something for the first time.  As a Scrum Master, having an open mind is critical.

I know, personally, I have been put with new teams – just coming together and finding myself less patient with them because I KNOW what’s coming.  But, really, I don’t.  I mean, it may be fair to say that I know where they will end up but that’s not the important part when a new team is coming together.  It’s HOW the team comes together that’s important and, if I’m less patient or dismissive, that can really impact the HOW and can also completely negate my “where they will end up” comfort.

There was a team I worked with a long time ago and the set up was somewhat screwy.  Despite having learned that I don’t know it all several times over, when this team started, I wasn’t in the right frame of mind.  There was a lot going on for me and I wasn’t invested in them.  I wasn’t really there to help them.  I dismissed their concerns and told them to “trust me”.  Rightfully so, they didn’t.  Why should they?  I was very clearly not engaged.  My mind wasn’t open to them and theirs sure wasn’t open to mine.  This team was completely new to Agile and I was doing them a disservice.  I didn’t want to go through their phases with them.  I wanted them to hurry up and get there.  You can imagine how well that worked out.  It didn’t.  Not at all.

I did recognize it and made moves to correct it quickly but, it didn’t matter much.  They had no reason to trust me, value my opinion or seek my advice.  What resulted was dysfunction at my hands.  It was a complete waste of an opportunity for them and for me.  A Scrum Master has a special relationship with a team because her focus is the team.  She can shape the safe environment teams need to learn and grow.  She can guide them through learning Scrum and help them chart their course to greatness IF two things are true:

1.  The Scrum Master has opted in and has an open mind to her new team.

2.  The Team has an open mind with regards to the Scrum Master and tackling Scrum.

I believe, if you begin with an open mind, there’s a bigger potential for greatness.  With an open mind you listen with the goal of understanding.  Being open automatically requires courage which is definitely needed when charting new territory.  Openness allows you to view your team positively.  Openness nurtures trust. When you’re listening, exploring, trying, brainstorming with the team, you’re building that trust and camaraderie.

As a Scrum Master, when you find yourself in a new environment or situation, don’t bring the events of the past with you.  Open your mind to what is possible.  Keep your eyes wide to observe and listen.  Remember that, though familiar, it’s only familiar to you.  Explore the solutions with your team with minds wide open and you’ll find the journey will be full of learning for everyone.  Even you, the Scrum Master who (thinks she) has seen it all.  Every team is different and so is their path.  Be open to their adventure.

Agile Adoption is Not an Easy Road – Make it easier

An Agile adoption has the potential to super-charge results.  The methodology is simple, rational and makes complete sense.  This  is probably the reason why so many companies give it a go.  Something that is often overlooked when considering Agile adoption is the fact that moving to Agile will, in addition to improving your ability to deliver value faster, expose the things in your organization that aren’t working.  And, it won’t be subtle.  As soon as you start moving, you will start hearing about the problems.

Organizations need to be prepared to hear these things.  They cannot be defensive or try to hide or ignore them.  They need to  fix them….FAST.  It’s a good idea for organizations to acknowledge they probably have opportunities and be open to hearing the reality from the team members who are feeling the pain.  If you’re not willing to listen and act what will happen is apathy, disengagement and Agile Adoption failure.  All the energy you had going into the adoption from the teams will fade.  Team members will likely go back to the old way of doing business and feel resentful about having to fake Agile.  They will stop telling you what is wrong because they know you either won’t act or they will actually get in trouble for raising the problem.

The organization may feel frustrated because they have all these Agile teams working on delivery.  They have spent gobs on training and coaches.  They have re-engineered their metrics.  But, they are not seeing massive improvement.  They will look at velocity.  They will assess the teams.  They will conduct focus groups.  They may hire outside help.  They will spend serious time and money to figure out what the heck the problems are and they will likely find the problems are the same as those they heard about in the first month of adoption.

There’s loads of information out there about the typical problems organizations face when moving to Agile.  It’s not a big secret but, an organization has to go looking for it.  There’s an opportunity to talk about this openly and candidly before pulling the trigger to set the expectations for leadership and define the behaviors leaders need to exhibit and demand from their management in order to create an environment for success.  Delivery teams will appreciate it as will leaders who truly want to improve and be successful.  It establishes openness from the very start as well as initiates the shift to servant leadership.  Finally, it gets people thinking in terms of trying, failing, learning and trying again.  Continuous improvement…

I hadn’t thought about it in this way before.  Honestly, I figured it might be best to just get an organization started.  Jump on in!  But, I believe it’s a disservice to the people in the delivery teams who will be trying their best to make this work.  Giving leaders visibility into the lessons learned by others and encouraging new behaviors and approaches is a good thing.  Imagine how cool it would be for team members to hear leaders from the very top all the way down saying “I want to know what’s wrong so I can fix it for you.  I don’t want you to have to focus on the problems or be held up by them.  I want to know so that it’s easier for you to be as awesome as you can be.”

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.

Speaking of Fear…

Today on Pinterest there was a great quote:

“You must do the thing you think you cannot do.” – Eleanor Roosevelt

Isn’t that awesome?  There’s conviction – you MUST.  Ed, very nicely, said my last post (on overcoming fear) was a bit different and it’s true.  It is different than most of mine, but not completely.  Fear is a difficult topic for me.  Generally, when people tell me I cannot do something, I consider it a throw down and set my mind to proving them wrong.  However, there’s a LOT I tell myself I can’t do and I don’t have the same view.

I mean, if I’m telling myself I cannot do something, I must be right.  Clearly, I know me better than anyone else.  But, that’s the thing…it’s hard to see what you’re capable of.  There are things I see in other people – their potential and talents – isn’t the same true about me?  The answer is yes.  There are some things I *think* are true but I don’t admit it to myself.  It feels wrong somehow so I end up being my own worst enemy.  I put myself down.  I talk myself out of taking a chance.  And, all for no good reason other than fear. And, fear isn’t a good reason to NOT do something.  Unless it’s morally wrong.  In that case fear is a GREAT reason.

Fear is in my rear view mirror at this point.  I’m working on doubt now.

How do you overcome fear?

When dealing with change of any sort, there’s an element of fear and your ability to confront and conquer it will be essential to your success negotiating it.  When you’re transitioning to Agile it’s a new way of working and thinking.  When you switch teams it’s not knowing who your team mates are, what they value and what they expect from you.  When moving to a new job it’s about who you’re working for and if you’ll be able to do well.  Often, fear also influences how you make a decision.  The fear of the unknown keeps you from doing something.  So, how do you conquer fear?

1.  Determine why you’re afraid.  If you can understand what scares you, it will help you rationally assess the validity of the fear.  Once you determine the validity….see number 2

2.  If you’re a glass half-empty kind of person and have identified why you’re afraid, you can then ask yourself “What’s the worst that can happen?”.  Thinking this through is pretty interesting and can really generate some good insights.  Often the worst thing we can imagine isn’t so terrible.

3.  Figure out what would need to be true in order for you to NOT be afraid and work towards making them so.

4.  Just do it.  Take the leap.  Personally, this is not my style.  I’m just not that kind of girl but, I started to do smallish acts – saying things I would normally filter and questioning when I would normally agree – and it became easier.  I don’t sputter and turn red nearly as much any longer. 🙂

One truth about fear…If you make decisions based out of fear, you will be opting out far more often that you will opt in.  By not opting in you limit your learning.  By limiting your learning you limit your growth.  I don’t know about you but, I don’t want to be the same person I am today years from now.  I want to opt in, learn and grow.

As a Scrum Master, consider this as you’re working with your teams and the individuals on those teams.  Trying new things, learning new skills, questioning, challenging and always evaluating can be scary and teams need every single one of those things (and then some) to be high-performing.