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.

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.

Does This Feel Like We’re Fighting The Scrum Master?


fencing

Invariably the time comes.  Hopefully it is a passing moment rather than a normal state of contention.  A team is trying to relegate their scrum master towards insignificance.  There are lots of ways to do so.  In fact, perhaps this is fairly easy since it is many versus one.  When we talk about the scrum master in software development – this is a role that is part of the team and yet has a very special  charge.   Teams that I come across are ever unique.  However, there are still patterns to behaviors that trip the ‘spidey sense’ and make me ask a bunch of questions.  In fact it is far easier for team members to attack than it is to consider, engage, problem solve, and change.  It is all right to disagree.  What should emerge from disagreement is what one thing we cherish over some other thing though there may be value in both.  Here are three team behaviors or attitudes to watch against.

Tag You’re It.  This is the hot potato role that the position of scrum master can be passed around the team.  Short interim, sure it can. No situation is ideal.  Longer term though, and we risk degrading the role so much that we lose our team advocate.  This role holds a unique perspective on how the team is interacting.  Someone to map to the framework and agile principals.  It might be a darker side, but I have the tendency to think that most things in the universe are in a state of decay. That vigilance and endeavor are needed not only to repair and sustain – but also to improve.  A person dedicate to the role is afforded the time to grow with it.

You Don’t Know Me. Anyone tasked with needing to change our focus, or the way we are thinking about things may have a really rough time. Admittedly my high school teachers are owed some profound apologies and thanks.   In a similar manner, if our scrum master doesn’t code, this doesn’t mean that they have no ideas on how to help in some way.  I’ve heard Quality Assurance testers say that their brains were far different than the scrum masters’ or even developers’ and that two would never meet.   I had to counter Really? Although we may think along different paths, the brain (when used properly) never ceases to amaze me when at it’s best, how flexible, creative, and genius it can be.  A team, ideally, might represent everything it might take to get the software through an organization and into the customer’s hands.  While doing so, they leave nothing untouched.  The team itself, the organization, the software may all be changed for better by the experience.

Believe it or not, the team includes the scrum master.  For the team to improve, this also means the team including, involving and being honest with their scrum master. Usually the scrum master helps motivate the rest of the team.  The reciprocal is also necessary – we all have our moments of hesitation.  We share in this experience and all should be left better for the having of it.

Are we all growing?  The scrum master usually watches for level of thinking – are we in the details, the general work, or the larger and longer release goals?  Is now the time to be talking about this or can it wait until a more appropriate time?  How are we interacting as a team?  How efficient and effective are we? Are we growing? Are we heard?

Fight the System. The scrum master, or even a coach is identified as a sole representative of ‘the way’.  We fight ‘the way’.  I can think of 3 or 4 other REALLY heavy release processes which are far less effective than Scrum.  I even saw the havoc these processes created with their false sense of security or the heavy burden and burn-out placed on a few people in the last phased functional role for the deliverable.  We might pin our failure on advocates or simply check out.  Process isn’t a bad thing, we just need to keep it in context and ensure that we control the process and not that it limits us. Perhaps we are too overwhelmed and everyone is operating on fumes.  This says something about our sustainable pace.    When we as a team place emphasis on the fighting, the passive-aggressive, or passive-defensive… et al. we are only fighting ourselves.  Fighting our own ability to change and be agile.  It is a funny thing which Phil Goldberg noticed and wrote Get out Of Your Own Way.   This self defeating behavior is as prevalent within ourselves just as it can manifest within a team.  I am mindful that I like people, and that there are just behaviors I don’t tend to find particularly helpful. Thinking can be a biological high energy state to form new connections… habits are entrenched, comfortable pathways.

I’ve brought up the point before, that in sparring with someone, we are partners.  We are both trying to improve ourselves together, testing, practicing, trying new techniques together.  We are really gearing up to tackle some rather difficult challenges and thought-work.   The best teams are balanced, across their members, in their ability to do this. Great teams also exhibit a tempo across differences or unknowns that allow them to adjust, learn, adapt, and try.  I want my team to improve and level up, as I expect no less from myself.  A great scrum master is not only an asset, an advocate and an ally for any team – they spark and fan the flame that every team inherently possesses.

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

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.

They’re NOT Overhead!

GAH!  Do you ever hear that statement in relation to stand-up, planning, retro and demo?  I do.  I hear it far more often than I would like to.  Often I hear it’s because the Scrum Master isn’t good.  It’s not just a Scrum Master responsibility though and, generally, that’s not the case.  Sure, for a new team, there’s a need for the Scrum Master to facilitate and teach.  No doubt about it but, when a team is knowledgeable about Agile and Scrum AND has been together for a while, the team can own the solutions too.  However, sometimes, you hear other reasons why I think a team member would feel this way:

1.  The ceremonies (I really can’t stand that word) aren’t useful to the team members and take WAY too much time prepare for and conduct.

2.  The team wasn’t listening during all that training about what they’re for, who they’re for and who owns making them useful and productive.

Too often, I also hear people blame training for the reason things aren’t working or say training is THE answer to the problem.  Since I disagree with this more often than not, I’m going to focus on number 1.

Stand Up – It’s for THE TEAM.  It should take no more than 15 minutes and you answer the 3 questions (when you’re just starting out).  If it’s taking longer and it feels statusy, then, you’re doing it wrong.  It’s not just the Scrum Masters job to point this out and keep the team on track.  Come to stand up prepared.  Don’t just look at the board once a day.  Listen to what your team mates are saying and get in the practice of holding each other accountable.

Planning – It’s for THE TEAM.  It’s when you decide what items to pull off the product backlog and how you will as a team execute.  It takes a while when a team is starting out.   If it’s still taking an inordinate amount of time and feels like overhead, get to the heart of WHY it is that way.  Maybe the team isn’t focusing.  Maybe the stories aren’t written well.  Grumbling about it being overhead won’t fix it though.  It WILL make it worse.  Discuss, investigate and experiment but don’t continue to complain about it.

Retro – It’s for THE TEAM.  It’s where the team takes time for themselves to reflect on how they’re working as a team.  It’s to identify ways to improve – AS A TEAM.  To me, it’s the most important of the ceremonies (there’s that word again).  If it’s not useful, read Esther Derby and Diana Larsen’s book on the topic: Agile Retrospectives:  Making Good Teams Great.  Continuous improvement is a Hallmark of a high performing team.  If you’re complaining it’s overhead, you’re not on one and you should do something about it.  By doing something about it I do not mean you should leave the team.  I do mean you should step up, learn and apply it.

Demo – It’s for THE TEAM to demo to their Stakeholders how they delivered on their commitment.  It’s to get feedback and show off how awesome the team is.  If it feels like overhead b/c you’re prepping for three days for it.  STOP prepping for three days for it.  It shouldn’t be onerous.  It should be demonstrative.  As a team, decide how you will conduct demos going forward and start experimenting.

Teams are empowered.  Team members are empowered.  You don’t need to wait for someone else to fix it.  As a team member, you can and should fix it.  Your Scrum Master can help.  If you really, really want to lose the “pain” associated with the ceremonies (dang it!) learn how to make them effective as they’re described and, as you mature, modify them to suit the needs of your team.   Also, you need to want to be a part of a team and a solid, if not high-performing one, at that.  Teams need to start somewhere and complaining isn’t starting.  It’s just complaining. Teams succeed or fail as a TEAM.  That applies to how they work together as much as the product(s) they deliver.

So many options….so little time. What to do? PRIORITIZE

So often I am amazed at how much I learn with regards to Agile that applies to my own life.  Most recently, prioritization was front and center.  I had a difficult and personal decision to make and I was truly struggling with what to do.  I was torn and, frankly, I didn’t want to decide.  I wanted to have it all!  ( Now if that doesn’t sound like some Product Owners and Business Stakeholders I don’t know what does.)

I reached out to someone I thought could help and, what do you know, he did!  How I got to meet this mentor is a great story which I’ll save for another time.  Anyway, his guidance was to sit down and not focus on my decision.  Instead I was to focus on my longer-term vision.  Now, I will say my vision is still a work in progress, so don’t think you can just bang out a vision in 10 minutes and be done with it.  Once I had the vision (in pictures ONLY) he said to put words to it and really think about what was non-negotiable, open for discussion and nice to have.  Then, take the opportunity I was considering and compare it to the vision and the words.  I did as he suggested and my decision was clear!

In delivery, when you know your long term objectives or vision, it’s MUCH easier to prioritize all of the cool things you could possibly do.  If the vision isn’t clear, well, you could spend a lot of time, effort and energy on something that won’t bring you closer to your vision and that’s not OK.   It’s not OK for the team, for the users OR for the business.  If you’re not spending energy on things that bring you closer to your vision, the odds are good you’re spending it on things which will (likely) take you further from it.  The true waste is you won’t know until you’re so far away and it will be harder to to get back on track.

It is a little shocking, when I think back on all the teams I have worked with, how many times I have heard “We HAVE to have EVERYTHING!”.  Funnily, in our own lives we know having it all isn’t generally possible but, in work, it can get dangerously close to normal.  And, how is that acceptable?  It shouldn’t be.  There should be uber-clear goals a company is trying to reach and the things they are trying to do should enable getting closer to the goal.  A Product Owner who doesn’t understand the vision will not be able to explain the context to the team.  This means it will be ridiculously challenging for the team to work quickly and efficiently.  Without context, the how becomes guess work.  If the Product Owner doesn’t understand the vision, there’s not a snow balls chance he will be able to effectively prioritize leading the team to work on things that aren’t valuable.

As a Scrum Master insist on the Product Owner reviewing the vision with the team.  Allow for an appropriate amount of time to ask questions.  Encourage the team to understand the thinking behind the prioritization and to challenge and suggest things to be considered by the Product Owner. This is the environment to strive for.  Mutual understanding and benefit. Understanding the vision and fostering this type of relationship with the Product Owner is powerful.  It’s powerful enough to allow a team to take off and deliver amazing things.

It still hurt to make my decision.  I really, really wanted to give it a go.  It wasn’t the right opportunity at this time in my life and I was able to be at peace with it.  Of course I want it all.  Who wouldn’t?  That said, knowing the context of how that one “thing” fit into the larger picture was critical to me.  Understanding the product vision and the resulting prioritization is one of those concepts where everyone will nod their heads and say they get it but, do they?  Do you?  We need to focus on the right things so we are always getting closer to the vision and doing amazing things.  As close as we possibly can anyway until we’re satisfied.

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.

The question challenge! Who’s in?

Something I often try to remind myself and team members is to listen to understand rather than listen to respond.  It is ever so much easier to say this than it is to do it!  So, next week, I’m going to try to ask at least one question before I answer, respond or comment on anything and see what happens. I hope to accomplish the following:

  1. Provide better and more thoughtful responses to those seeking them
  2. Stop myself from just speaking and ingrain better listening habits
  3. See if, perhaps, my questions generate something for the person I’m speaking with
  4. Determine who is courageous enough to opt in and try this with me

And, I’m going to let my teams know what I’m doing and invite them to do the same and see who opts in and what happens with them too.  I’m also inviting anyone who is reading this to join in.  Come back here and write about your experiences.  The good the bad and the awkward!

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.