Who am I?
I’ve been to many conferences and the first thing I wonder in any presentation is “who is this person and why should I listen to them?” My name is Bobby Pierce and I’ve had the opportunity to lead support, development, and QA organizations. I’ve done several multiple organization transformations several of which we were Agile. I’ve done some at the team level and some at scale. I’ve done some things well and others completely wrong. I’ve helped bring SAFe to an organization that didn’t know what Agile or scrum were. I’ve overhauled existing Agile structures impacting how 1000s worked all the way up to the C-level. I’ve driven cross-organization wide Agile transformations for both technical and non-technical teams. I have a lot of experience with Agile and transformations in general from many different angles.
This is who I am within the context of Agile, but why should you listen? I’ve messed this Agile thing up. That’s why you should listen. I’ve done it wrong multiple times in multiple ways just so I could get it right a few times in a few ways. I’m hoping you can listen to what I’ve learned from my missteps and not my successes.
A Story…
When I was 6th grade I wanted to play sports. I wanted to play all of them, but specifically I had a love for basketball. This was the mid-90s so I was a Jordan fan, and I wanted to be like Mike. My school was small and we had 3 basketball teams. An A, B, and C team each generally corresponding to 8th, 7th, and 6th grades. I was going to try out for the C team, and since my school was small I knew all 16 people trying out. 12 would make it and I knew I was in the top 12. After tryouts they posted a force ranked list (yes 1-16 in order) on a piece of paper on a bulletin board. I was #13. I didn’t make it. I was immediately floored. I didn’t know what to do, but for me something was very clear… this was the start of my basketball life and not the end. I knew I was going to try out the next year and I knew I was going to play basketball for a long time. This was a big blow. All 12 kids would now have a full year of games and practice as a head start. I didn’t know what to do…
I decided I was going to become better and make the team the next year, but how? I tried a few different things. I asked for a basketball hoop as an early christmas gift. I got one which was great. I could now practice at home. However, we had to put it in the backyard where there was no pavement. I could shoot, but couldn’t dribble. I asked if I could dig up the entire yard, but alas I wasn’t allowed. I’d have to learn to dribble in the driveway and other places (certainly not in the house). I asked my friends to play with me on the weekends. We played a lot. Finally I asked the coach if I could practice with the team even though I didn’t make it. I told him I understood I’d never play in a game, but I wanted to try out next year and this was the best way to get better. He agreed and I practiced with the team all year. I continued to practice on my own and with my friends.
I came back the next year to try out for the B team. With all my practice and a little growth spurt I made the B team. I went on to be the only 7th grader to play on the A team that year. The next year I was a captain of the A team and went on to make the high school team. I quit playing competitively after that, but basketball was a part of my life.
What does this have to do with Agile?
While this is a simple story of a boy growing up what does it really have to do with Agile? Well the first thing is that like me I think you’re here because you’re on a life long journey with Agile. You want Agile to be part of your work lives in a big way. More importantly this simple story follows the same pattern you need to in your Agile journey. There really is 1 and only 1 pattern that matters regardless of wherever you are in your journey. It’s going to sound overly simplistic, but it should be your guiding light especially when you get started. Here it is.
- Find a problem or opportunity
- Research/find potential solutions
- Assess solutions for fit for purpose in your situation
- Rally support & resources
- Implement & adapt
- Go back to step 1
That’s it. That’s all Agile transformation is. In fact I told that story to demonstrate that this is really what ALL transformation is. What’s critical here is that this is a natural way to break big problems down into smaller problems. You can start big and repeat this loop.
- I didn’t make the C team, but wanted to play basketball
- Many options: get a private coach, play on my own, get a basketball hoop, watch videos, give up, etc
- What could work for me: basketball hoop, play with friends, practice anyway
- Ask for the hoop. Ask friends to play. Ask coach to practice
- Get hoop. Start playing. Start practicing.
- Back to step 1 – hoop is on grass… what do I do now?
Each of the individual paths can be considered its own iteration, but for the purposes of this talk I’m lumping them together. This works with Agile too.
Navigating Agile Transformation
The diagram below shows this pattern in a bit more of an Agile context.
There are several key things within this diagram, but the first is that you need to start with the beginning. How many people have been part of or heard of an Agile Transformation that was simply a scrum or tool implementation with no real goal? I’ve heard of many of them. Certainly each situation is unique, but I’d venture to guess that in all those cases some of these steps were skipped. It’s likely one of a few scenarios. The first is that there was no problem or opportunity. “We need to be Agile” is the rallying cry of such initiatives. It’s possible they identified something like “speed to market” in the first step, but got lost somewhere in the next 2. Is using JIRA really a solution to make your teams go faster? Likely no. Maybe you’re already practicing agile with stickies that work well and someone thinks using a tool will make you faster, but it’s not really fit for purpose for your teams. Maybe you did EVERYTHING right in identifying a solution, but forgot to really REAL support. This happens with a lot of top-down pushes. The leader decides this is the way to do something and “orders” people to do it. What happens is that once the leader leaves the room the team decides to move backward or bastardize what they were asked to do. Leadership buy-in is different than winning hearts and minds. Finally, maybe you implemented a rigorous JIRA workflow and never adapted it. Something happens and it no longer works… oops.
There isn’t time to go deep into each and every one of these so I’d like to focus on “Fit for Purpose”. This is the box that I think separates success from failure the most. This is where I see Agile coaches fail the most. This is where I personally struggle the most. There are several key items that you must have or build here…
- “It is easier to act your way into a new way of thinking than think your way into a new way of acting.” -Jerry Sternin
- TRUE Empathy & Understanding
- Willingness to meet the team where they are
Too often I hear that some book or doctrine has all the answers. Maybe they do for the end game, but how someone gets there is going to be unique to them. My basketball situation answer was very straight forward: PRACTICE. That’s it. I needed to practice. However, my implementation was unique to my situation. Agile is the same way. Sure Agile Values like “Individuals and Interactions Over Processes and Tools” is a better end game, but if you’re not there today you can’t get there overnight. This is where Fit For Purpose comes into play.
The first key to this phase is a quote from Jerry Sternin “It is easier to act your way into a new way of thinking than think your way into a new way of acting.” What this means is that in order to get the changes we want we need people to act differently. That often does mean mechanics like process changes or tools. Usually our intended goal is something more meta and longer lasting, but in order to get people to embrace something like “a culture of innovation” we need to force habitual change. This is more psychology than Agile. Humans don’t change by thinking about change or being told to change. They need to develop habits by doing.
In order to understand if things actually fit you need true empathy and understanding for the people you’re changing. This is often missed. Empathy doesn’t come from interviews, surveys, or maturity models. It comes from walking a mile in their shoes. If you’ve managed development teams like the teams you’re trying to change this is much easier. If you haven’t you can literally walk a mile in their shoes or find someone who can partner with you to drive this change. What’s key is you truly understand what they do and why they do it. The best way to know you’ve hit this point is to try and represent it back to the team or key person. They’ll tell you if you’ve got it.
The last key, and the hardest for me often times, is to meet the team where they are. If you’ve got empathy and understanding it’s possible you’ve seen this situation before. You might know all the right answers, but that doesn’t matter as much as meeting the team where they are. If they are not ready to listen you need to back off. Often times this means changing your solution and fitting it to the team. Often times it means doing less more slowly than you really want to do. That’s ok. If you meet the team where they are your next step becomes much easier. If you want to forge ahead the next step of winning hearts and minds will take a lot longer. Implementation will be a lot less successful. I believe doing less for a better fit for purpose will save you time in the long run.
A Real LIfe Example
In mid 2015 the group I worked in within Nielsen was ready to get serious with Agile. We’d heard about it and believed there were lots of benefits. Nielsen had used XP in the past, but had gone strictly waterfall. Our first retry with Agile was actually a pilot in late 2014 with 2 of my dev teams on a newly created flagship product. We were told to “do more and go faster, but you don’t have to necessarily use Agile” wink wink. I read a book about scrum and “implemented” it over the weekend… without getting into it too much this proved to us that Agile could help. We experimented with Agile in 2015 not knowing how to do it or what we wanted out of it. Finally in late 2015 we came to our hypothesis statement: “We don’t have any idea what our resources are REALLY doing. If we get transparency and visibility into what they’re REALLy doing we’ll see a lot of improvement opportunities.” Thus our goal for scaled Agile across 2000+ people was “Transparency and Visibility” with the idea that we’ll come back to improve things like throughput later. I think for a transformation of this size we did step 1 well.
Moving along we tried to figure out how to achieve this transparency and visibility. We spent the next couple months bouncing back and forth between solutions and fit for purpose. We brought in multiple consulting companies to help. We dove deep into SAFe. We dove deep into tools. We did our best to figure out how we were going to achieve basic transparency and visibility. We landed on a modified 3-tiered SAFe like model with all scrum teams using JIRA, no exceptions. We landed on scrum only. No kanban for any scrum teams. It was pretty prescriptive, but we had to get people to act differently in order to think differently. I was part of the team helping define these things so of course I thought we were on the right track.
The next phase was to rally support and resources. Things like licenses and trainers weren’t all that difficult to get. Support is what we needed the most. We did the basics. We started top down to get support within our own organization. This worked well at the top. We spent a lot of time making sure leaders were on board. This is where we had our first misstep in my opinion. We didn’t do enough to go beyond the leaders to convince middle managers and doers. We had some rah rah type sessions to get people enthused, but we didn’t take the time to explain our goals. We didn’t take enough time to explain why. In addition we didn’t rally our stakeholders. It was an “our house first” kind of change. To this day I’m not 100% sure if that’s the right move or not. I’d like to say we could have done more, but I tend to think we had to meet them where they were… they didn’t want to hear about Agile. They wanted software and results.
We then went on to implement our modified version of SAFe. We rolled it out 3-4 portfolios at a time with my portfolio being 1 of the first 3 teams. It went reasonably well. We wanted transparency and visibility to identify problems and we got that. I knew all of this because I helped implement, but alas most people didn’t.
This is where we started to skip steps. We never went back to update our original organization level goal. Did we want speed next? What about quality? Maybe culture? Who knows? We never replaced it with another stated goal. Furthermore even at a micro level we started to skip the first step. We rolled out things like a strict PI Planning process for all groups. There was no stated goal other than “this worked somewhere else”.
After a while Agile got a bad name in this group. People were frustrated and called it a failed transformation. At this point I became the single owner for Agile in this group. We pivoted and went on to make many more changes, but the reputation remains. We decided to skip steps in this pattern and paid the penalty. The sad part is that it 100% achieved its goal of driving transparency and visibility. Some teams even took it to the next step to improve their world as a result. It met its first set of goals, but people won’t remember that. It was both successful and unsuccessful. We somehow somewhere forgot the pattern.
Conclusion
I’d like to leave you with some parting words and then ask you for help on something. We are here today to build connections and learn. We’re here to expand our knowledge of potential solutions and how they fit within some organization. Embrace that. Listen to stories and catalog them. Make connections and use them. Don’t forget though that Agile doesn’t happen in a textbook, slides, or my speech. It happens within some company or organization. Your own context and your own situation is key.
My ask is simple: try to break my pattern and tell me about it. Find situations where you skipped a step and it worked. Find situations where I’m missing pieces. Tell me I’m wrong. I want this to evolve. I want to apply this pattern to my view represented here, and yes I want to apply the pattern to the pattern itself. I need problem/opportunity statements from you to do so.