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

Advertisements

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.

Value is POWERFUL for people and work

In the last week I have been hit hard by the reminder of how powerful value is.  There are two instances I want to highlight.One is related to people and the other related to stories.

VALUE YOUR PEOPLE

It’s important as a Scrum Master, a people manager or a leader to show the people you work with and for that you value them as a person and for the work they do.  When a person feels valued, they are motivated.  And, I know, everyone is motivated by different things.  For some, it’s money.  For others, it’s recognition.  There are many things a person may be motivated by but, all people need to feel valued.  If they don’t, they disengage and that isn’t good for anyone.

You need to find out what is unique in the people you are surrounded by.  It doesn’t matter if you manage them, lead them or work for them.  Identifying what makes an individual special is powerful…for them.  You can find ways to build on it, leverage it, showcase it and help the person shine.  When you make someone feel valued, they will return it with awesome performance and, even better, loyalty.  If you’re not investing thought like this into your people, please, take some time to do so.  Have a conversation.  Find out what they’re passionate about.  Discover what they’re good at doing.  Learn about what they want to learn about.  Invest in and value people and the dividends are endless.

VALUE STORIES

People want to be valued and they want to work on things that are valuable.  In a SAFe release planning event this week teams had identified the features they were delivering and broken them down into stories.  In SAFe, teams then specify their release objectives.  It’s a layman summary of multiple stories which, Product Management then values on a scale of 1-10.  Keep in mind teams are working in priority order so, the initial thought is their focus is on the right features.  When you break a feature into stories and specify exactly what the objectives are for the release, what happens is amazing.  A conversation with a group of Product Managers and the team takes place and, often, a high priority feature has objectives associated with it whose value is mixed.  We’re all about delivering value right? Here’s an example over-simplified:

EPIC – Build  house

Feature – Build Front Entrance (priority = 1)

Feature – Build a Deck (priority -2)

Objectives –

–  Complete deck to hold more than 6000 lbs. – 9

–  Complete steps to front porch – 10

–  Complete front porch covering – 4

–  Paint front door – 1

– Complete rails around deck – 8

– Build grill bump out – 2

When you look at it, there’s more VALUE in completing items associated with the lower priority feature.  Good to know for a team.  Very enlightening to Product Management.  Awesome conversations and understanding generated between delivery and the business.  All is all, just goodness.

In summary, there’s power in focusing on value – for the people and the work.  See what you can do tomorrow for people.  Make someone’s day.

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.

The Bond Between a Scrum Master and The Team

I was asked yesterday to describe the difference between a Scrum Master and a Project Manager and an odd metaphor popped in my head.

When a team has just won a game and the coach is interviewed afterwards they don’t say “Yep.  The team followed my instructions and plan exactly.  They executed what I wanted them to, when I wanted them to and how I wanted them to.  That’s why they won.”

They say things like “The team gave their best today.  They have been working hard together all season and, today, it all paid off.  They were amazing out there.  They deserve this win.”

I’m not saying a PM would actually take credit for the end-product of a team.  I am saying that the coach puts the emphasis on the team and the PM puts an emphasis on the plan and the execution of it.

This mind shift is essential and not an easy one.  I have found the relationships between me (as a Scrum Master) and the teams I have worked with are all very different with one exception.  Every single one has been based on trust.  When there’s a strong bond between a Scrum Master and the team, from my point of view, there’s nothing more fun or cool.

The team helps you grow by challenging you to be better and think differently. Their learning outpaces your own!  And they’re learning because they trust you, their Scrum Master, to make good suggestions and they’re willing to try things.  Sometimes, in my head, I will think “I dare you to be even better than you already are.”.  You can see them as a single entity and the possibility of the whole.

Scrum Masters also connect with the individuals on the team.  Many of my good friends are from previous teams and they are not people I would have known well had we not worked so closely together.  A Scrum Master can see things that are possible in an individual that the person may not even be able to see.  The same is true for the team member.  Often, team members have taught me things I never would have thought about or seen in myself.  Some good and some not so good but all said with the best of intentions.  The team members and the Scrum Master can help each other learn and grow individually.

I can’t speak from the team member perspective on this final point.  I feel very protective of my teams.  When they have great things going on and happening, I want everyone to see how awesome they are.  When people are messing with them, in any way, I feel very Mama Bear.  I may actually get a little too “bear”.   When they achieve greatness, I don’t want anyone or anything in their way.  When they’re on their way, I want them to have the space and room to work their way towards it.

When people ask me now why I am so passionate about Agile, the answer is simple.  It’s the people.  I can name them all.  I can tell you why each one is special.  I can tell you everything each one of them taught me.  The bond is built on trust and is powerful because you learned so much with each other.