Here’s A Little Story About My First Change Experiment

As my boss pulled me into a conference room, I could tell we were about to have one of those serious talks again. Over the past year, as I was starting to take on new responsibilities as our agile champion, he would pull me into chats to discuss some of the challenges teams were having.

I was humbled, and at the same time completely out of my depth.

Most of my coaching opportunities had been one-on-one up to that point. Work with this person on planning sessions. Ask another if I could sit in with their next retro. Could I train this individual on the 12 principles?

This chat was different, because he was asking about an entire division of the company. A group of many teams that work on a mobile application platform. A framework capable of producing skinned versions of the same app for various clients.

The challenges they weren’t having should sound familiar to many. Teams were having trouble meeting deadlines. As a result, clients were frustrated. The turmoil had team members begging off the project. In general, this group of teams needed something drastic to change, and he asked if I was interested in helping at all.

No big deal for your first ever change management experiment.

The story I’m going to tell is part of a case study I presented at this year’s Agile Alliance conference on theme of what happens when we move way too fast. It was an amazing learning opportunity for this coach, and I use the lessons with every new team I encounter today.

Just how does one get started when given this chance?

Understand the issue before you plan.

Before putting a plan together, I interviewed many of the leads from every discipline (project management, development, quality assurance, dev ops, art/ux). The three main issues that they saw with their current process was:

  • It was almost impossible to estimate and meet milestones because of what they described as, “an unusual amount of uncertainty” with tasks.
  • Project management was too disconnected from the team due to client demands.
  • Teams felt like they never ended the day working on what they intended to.

Work was being shipped, but nobody was super happy about how it was going out of the door. Stop me if you’ve heard this before.

Also, my boss gave me some great advice to consider how I would measure the progress of teams. Many eyes were going to be watching, so I should consider how I wanted to tell the story of change. That’s a great reminder for every future assignment you and I receive.

Everyone’s always watching when you climb aboard change train, so proceed with caution.

Plan, but not too much at first.

The initial change management plan started out lean, taking a page out of Jason Little’s playbook. First, everyone would run Scrum by the guide. That way, I could easily implement the same workflow for all teams and jump in and out of team ceremonies. There were five of them, after all. Many of my peers on had some Scrum certs as well, which would arm me with trained advocates.

There’s another reason I chose Scrum. It’s helpful that some of my peers were familiar with the framework, but it’s awesome that I was also. When stepping out of your coaching comfort zone, don’t be afraid to lean on methods and frameworks you know well.

You can’t help people if you’re fumbling around in the dark alongside teams.

Consider measuring your progress.

The second part of my plan involved a survey. Some of my earliest agile teams had used anonymous surveys to capture what was going well and what wasn’t. Due to the instability of morale, I thought maybe this could be useful again. I had no idea of what data to capture or how to measure, though.

So, I enlisted an expert. Always remember there are experts willing to assist with ideas and credibility.

I asked our analytics and user testing lead at the company to have lunch with me one day. Describing the situation, and the request from leadership, we threw out a bunch of different areas to potentially measure. Honestly, if you’re wanting to track how your teams are doing, there’s no shortage of ways to measure progress.

We settled on a format that includes aspects of Net Promoter Score, the Happiness Metric, and Value Stream Mapping to measure five areas:

  • Overall satisfaction
  • Team productivity
  • Team communication
  • Personal productivity
  • Quality of deliverable

It’s a concept that we started referring to as Retrospective Stream Mapping.

We didn’t want the survey to be super long, or nobody would take it. The questions also shouldn’t be slanted to only tell the story we had already predetermined. Short, and general is what we decided. Using a scale of 1-10, and open text fields to capture why team members felt that way, we were all set to kick off.

How did it go?

Here’s part 2 of the story.

6 thoughts on “Here’s A Little Story About My First Change Experiment

  1. I’ve always liked the NPS type question. It’s a simple number with a qualified comment. I think people who think it’s a bad metric because it’s just a number are stuck in SHU and don’t realize there’s no ‘rule’ to using a technique! Thanks for the mention as well!

    Like

Leave a comment