My Light Bulb Moment

Thanks to Michele Sliger for asking me to write it all down!

I started out as an ”Agile Project Manager”.  I accepted a contract for an IT project (my first) and was told it would be run as an Agile project.  I had no idea what Agile was and I was a Project Manager.  I had a great track record as a PM of driving results.  I googled Agile and was thrilled to learn my entire team would be in the same room, everything they were doing would be on the board and we would only have a 15 minute meeting once a day to discuss the project.  Oh….how very wrong I was.  Mind you the team delivered after slogging through entirely too much overtime, continuous pressure from me and the business and constant driving.  Unfortunately, their work never saw the light of day – two weeks before launch, the project was pulled.  What had worked for me before didn’t work this time.  I heard a lot from the people on the team who knew what Agile was and I was decidedly NOT a Scrum Master.  I cared, a great deal, about the people on the team and there were certain things I began to grasp but not enough to make a difference for them.  Honestly, why I stayed in IT after that project is beyond me but, I did.

Following that project, the next team I had was already formed and doing well on their own.  I still hadn’t had any training but, was asked to be the Scrum Master.  I started reading more and asking more questions of those around me who seemed to get this whole Agile thing.  I came into the team sure I would make them different and better.  I came in without acknowledging or respecting their history.  I asked them all kinds of questions about the work they were doing, why they were doing things the way they were doing them, pushing them a little so, in short, I didn’t really learn much and it still wasn’t clicking for me.  It was not a very comfortable place to be for anyone.  Then, someone had the brilliant idea to combine two teams together – mine and another – and that was when things started to get interesting.  The team that joined my team DID get Agile and they were not at all OK about how I was running them.  They pushed back.  I went to CSM training.

Joe Little and Jeff Sutherland were teaching the course and, as I sat there, all the pieces started coming together.  I understood how it was supposed to work and how I wasn’t doing anything AT ALL to make it easier.  Jeff Sutherland made the point that I still true back to all the time:  Protect The Team.  I came back to work energized and excited.  It clicked and I couldn’t wait to get going.  That said, there was this HUGE team which was really two teams trying to keep their individual team identities in place and continue to be the good teams they were separately.  It wasn’t working. I knew, in theory, what I was supposed to do but I didn’t know HOW to do it.  They fought over desk position, norms, how stand up should be run, how planning should be run and we were all incredibly miserable.  I thought I was doing the right things and protecting the team.  I wasn’t.

I asked another Scrum Master for help.  He came to observe a retro and, at the end of an hour, told me I couldn’t stop.  I had to keep the team talking for as long as it took for them to work their issues out.  The retro lasted all day.  Seriously,  Everyone was open and honest including me.  There were things said which were really hard to swallow for me.  I really had been trying to do the right things.  They made me question everything I had ever thought about my abilities. However, after that retro there was something different.  We all realized we were all trying to do the right things.  There was no malice or ill intent.  We trusted each other a little and we had overcome a decent amount of pain together.  After that retro, I started reading, researching, asking and experimenting and the team let me.  I would tell them what I wanted to try and why and I knew they would tell me when I was off track. They would tell me because they knew I was trying and I wanted to get better.  They also wanted to be better.  We all wanted to be the best team possible.

So, we’re all on an upswing now and someone decides to split the team back up.  Yes.  After ALL that pain we needed to split.  I remember being in the room with several other people figuring out who would go where and they were all looking at me to make the new teams.  It tore me up though.  I had gotten close to everyone and they were doing so well but, I did it, and I chose the team I was going to stay with.  The team was named BOB.  We worked together for about a year and it was the single-most rewarding and fun time of my career.  What I learned from that team in terms of trust, what empowered teams can do, what protecting a team meant and what the role of a Scrum Master really was is what has shaped me and guided me to where I am now.  It is an experience I hope everyone working in Agile can have.

We were nearing performance management time and I was writing my self-appraisal.  I didn’t have anything to write.  I didn’t have any results.  There were no “BIG WINS”.  In fact, I sat there thinking I hadn’t had to do much with the team at all.  I started to get truly worried about what was going to happen come end of year.  With none of the usual problem-solving, risk mitigating, implementation strategizing and scheduling management-type-stuff my piece of paper looked really empty.

“Scrum Master for a team who has delivered more scope than originally requested within the same amount of time.  No defects released into production.  Team has created automated test harnesses to enable faster identification of defects and leverage the QS resource more effectively.  Team members have learned new skills to be more efficient in their delivery approaches.  The team manages themselves, including removing most impediments. The team has created a build book to be used by the platform and serve as guidelines for UI development.  The team is able to respond quickly to change and is frequently sought after by the business to help shape strategy and inform intent.”

The TEAM had done great.  They had knocked everything thrown their way out of the park.  They were having fun and everyone wanted them.  Then it hit me.  They did it!  They were a self-managing, self-organizing, high-performing machine.  That’s what is supposed to happen.



A Scrum Masters job is to work themselves out of a job

I didn’t realize this when I first started on my Agile journey but, it’s absolutely true. We talk about self-organizing, self-managing teams and I continue to see teams and Scrum Masters who can’t separate. I think some of it is organizational and some of it is…not.

When a company or department decides to “go Agile” they do it for the right reasons. They want to deliver value faster. The thing is, when you apply Scrum, it’s a massive mind-shift more than anything else and while the org may want to deliver faster, they still want all the other stuff they had too. Things like status reports, project plans, milestones…I have had people ask for the release plan .mpp. I understand the needs of stakeholders and executives but you can’t have it both ways. Don’t get me wrong, there’s a compromise to be had if the company is large enough. Lately, I’m thinking frameworks like SAFe address those needs nicely – we’ll see. So, you need a Scrum Master to deal with the paperwork overhead. If the Scrum Master is meeting this need they’re probably not focusing on getting the team to a high-performing place. Odds are pretty good the team is still working in the old way, just with a board.

The other reason could be that it’s mostly PMs who end up filling the Scrum Master role and unless he or she is willing to really shift perspective, it’s command and control with a team in the room and the plan on the board. It’s awesome for the PM!! Their team is captive and he can tell what is going on every minute of the day. That’s horrible for the team though. And, that PM is not focused on the team. He’s focused on the work.

My initial point of view was it was business as usual, but with a board and 15 minute meeting everyday. I NEEDED to know everything, control everything and be right smack in the center of everything. A good team, mentors and instructors taught me differently. It’s great when you deliver a project as a PM. But, let me tell you, it’s nothing short of awesome when you guide a team to that self-organizing, high-performing place and you realize you’re no longer necessary.

People are smart. They want to do well. They have good ideas. They are good problem solvers. These are basic truths. Team members will work hard for each other, their solutions and their ideas. To me, the job of a Scrum Master is to help the team learn how to do all these things within the Scrum Framework as simply and easily as possible. It’s not so much about protecting them from others. It’s about protecting the space they need to learn, grow and get to a place where you’re not needed.

Learning how to be a Scrum Master is hard

I was fortunate enough to co-facilitate a CSM class this week.  What can I say?  It’s been a true learning week for me. It was such a great experience.  It’s good to re-visit the basics again.  Other than this and my own CSM, I have observed one other class.  In all of them I came away with a different insight and refreshed thinking.  Since I had a different role in this class, I also had a different perspective.

This time, I walked away with an appreciation for how difficult it is to wrap your head around everything.  It’s overwhelming.  I can’t decide who it’s more overwhelming for though.  The person who is brand new to it OR the one who believes they have been doing it only to realize….not so much.

Then, on Wednesday, you’re supposed to go back and start applying it all.  GAH!  Honestly, I think the class could benefit from another day which at least touched on how to go about beginning to apply it all.  The transition to Scrum Master, for me, was not an easy one.  There are many facets of the role which didn’t come naturally to me.  Specifically the one about being in control.  Also, the one about letting teams learn through “failure”.

While it may not have come naturally, the role and the principles resonated with me.   They made sense.  Even as a PM I believed it was more about the people on the team than the plan.  The transition is something I really had to work at, think about and learn through my own, um, failures.  Also, those failures are hard because you’re talking about impacting people in a possibly negative way.  Ouch.  I’m thankful for the team members I worked with.  They were patient, understanding and willing to give me another chance.  In fact, I believe they were way more patient with me than I was with myself and, for a while, than I was with them even.

I guess my point is, for new Scrum Masters, don’t feel you should get it right away.  It’s a continual learning process.  It’s about trying things, reading a lot, finding a mentor and asking a lot of questions and making yourself vulnerable enough to try something and build on your experiences.  If at first something doesn’t succeed, try something else and continue to do so.   The other thing that goes a long way is to let people know you want to try something and ask if they’re willing to try it with you.  If you mess up, call it out and apologize.  If you go about it the right way with your teams, it will help build trust.  They’re not perfect and neither are you and that’s OK.

I am sincerely appreciative of the CST who let me co-facilitate.  It takes time from other work.  It takes mental energy.  It takes guts.  Had I tanked, it would have reflected poorly on him.  I’m hoping to find others to work with and continue on this journey.