USING INTEGRAL AGILE IN A SAFE ENVIRONMENT

Agile Transformation is a journey, and the larger the organization, the longer the journey takes. Many enterprises can be several years into their journey without achieving significant results or even widespread buy-in as the new ideas struggle against the sheer momentum of decades of traditional thinking. This client was such an animal. They had gotten as far as a “mandate” that Agile was the new way of working, but they hadn’t yet appreciated what that meant aside from some basic ideas about Scrum. The leader of our transformation team liked to joke that us Agile Coaches “were about as welcome as a fart in a space suit,” yet it was our job to win hearts and minds, and help folks understand that we were there to make their lives better, not just install processes and frameworks.

I was assigned as the principal coach to implement the  Agile transformation for the entire Marketing Organization while appreciating the constraints of existing in a traditional financial services company. Working with the president of the organization and his leadership team, and with the help of several other coaches on my transformation team, our task was to analyze every facet of the organization and build them a new structure to support their efforts to effectively market to their customers. 

I was going for a big win here… something other organizations across the enterprise could see as an example that there really is light at the end of the tunnel, if they could just relax their grip on doing things the way they were familiar with long enough to get there.

This particular challenge would end up requiring:

• Establishing Strategic Themes and OKRs
• Value Stream Mapping
• Creating new cadences at the org, ToT, and team levels (holons)
• Training at all levels
  • Leadership
  • Business Agility
  • Agile at scale
  • Team agility
• Deploying coaches to work with the various ARTs
• Creating new role definitions
  • Replacing traditional activities and reporting with Lean/Agile alternatives
• Moving teams towards increased cross-functionality
• Identifying and mentoring “change agents” (the people who would sustain the transformation after it was operational)

The Part Before We Get to the Good Part

To start things off I met with each leader individually to get their perspectives about the opportunities and challenges within each of their product and technical areas making sure to address all 4 quadrants. I then brought them together as a group to establish goals for the transformation of the organization as a whole, creating a 3 year plan.  This plan included objectives related to the Agile Transformation itself, Platform & Architectural Uplift, a complete reimagining of their Marketing Strategy, as well as every delivery target they had on their roadmap.

The scope was too broad to be able to effectively address it at this scale so we took a step by step prioritization approach based on the objectives they wanted to see on a year over year basis. We focused on the areas that supported essential objectives (the ones that could not slip under any circumstances), and created a plan that would align business, technology, and delivery such that they could quickly arrive on the good side of the J curve, so they could reap the benefits of agility. I was fortunate to work with a highly motivated group of leaders who understood that true change was going to be painful and would require a lot of work.

1. Everybody gets trained

I have a generally dim view of training an entire organization unless the folks being trained were going to use the training right away. In the current circumstances it made sense, because even though we were only going to directly coach half of the organization in our first wave, the other half would receive a streamlined training designed to familiarize them with what the first groups were going through so they would be compatible with the new processes and align themselves to the new cadences we were putting in place.

2. Leadership Buy In

Having the leaders on board was huge. Armed with the long term strategy for the organization as a whole, and a complete list of each leader's needs for their specific areas, our coaching team split up to cover the 4 major areas we were going to support first. Each of these consisted of 7-9 teams.

I’d love to give you the details of the success stories we created over the next 9 months, but I’m a busy person, and so are you, so I’ll briefly cover what we accomplished before I get to the good part.

What took place over the course of that time is that we were successful in hitting every metric we targeted, and those 4 areas of the Marketing Organization moved from being skeptical beginners to practitioners who took ownership of the results they were seeking. They still needed coaching support, but my time was freed up to go back to the president of the organization to see if he was willing to push things further. He was.

The Good Part

The launching of a cross-organizational, cross-functional Team of Teams (Agile Release Train)

One of the remaining groups we hadn’t started coaching yet saw what was going on in the rest of the organization and reached out to be the next in line for coaching. This was perhaps the most motivated group I had ever seen, and their energy sparked my idea for taking things further.

Over the course of the past couple of years working for this enterprise, I observed that the main barrier to Agile success had nothing to do with process or team proficiency, but rather lay in the siloed thinking and local optimization practices endemic to the dozens of different business and technology groups, all of whom had different priorities. In the end, of course, their objectives were the success of the enterprise as a whole, but by and large, teams and team members were incentivized to prioritize their own individual successes and achievements (even if that came at the expense of their colleagues). In a global enterprise of this size this is not an example of the right hand not knowing what the left hand is doing, but more like each individual joint having its own idea about what it was supposed to be doing. Good luck grasping anything in that situation, they sure couldn’t, but like water to a fish, they were unaware of the broader situation around them. Without seeing the whole system they accepted, and eventually became numb to, the pain they were experiencing.

Things were about to get a whole lot more interesting for all of us.

Before getting started with this new group, let’s call them Meteor, we did a demand-based analysis of where their work was coming from, and mapped out how that work flowed through their systems and teams, eventually making it to customers. We created a heatmap of the most heavily impacted teams. 

You can see on the diagram below where the team is on the left and the area of demand is across the top.

The selected area represents the 25 teams who were most impacted by Meteor work. Due to the way the platforms and technical abilities were dispersed across the enterprise, many of those teams existed in completely different organizations, and the communication and collaboration across those teams was minimal. This led to lots of dependencies, blocked items, and integration problems -- things that sapped the productivity from the teams and often left customers waiting for months to get what they needed as the teams struggled to align their backlogs.

I shared this information with the president of the organization and indicated to him where there were heavy external dependencies. After some back and forths, I got to most of the meat, and some of the potatoes of the matter: I wanted to initiate an exchange program of sorts, where we take developers from other organizations and offer in exchange developers of ours whose expertise would be of value. He had some questions about what the benefit to us would be, and how it would work, and after I answered those to his satisfaction he got  the heaviest impacted Senior Vice President on a video call and asked me to explain my idea to him. Fifteen minutes later I had buy-in from not one but two senior leaders! We were ready to rock.

Getting it done

We were in new territory with the transformation of the Meteor group. What is often called a transformation is typically what we referred to as Agile Adoption; the team(s) change how they are doing the work, but how they’re organized and how they get the work done remains largely intact. What was now in front of us involved constructing new, interdisciplinary teams, and helping them do everything necessary to coalesce, but it turns out that buy-in from the boss is only the beginning if you want to get stuff done in a large enterprise. 

The first steering committee meeting we organized to propose our plan involved 15 leaders, each with their own concerns and agendas. They were intrigued, but had many questions:

Question 1: “How is this going to work financially, does it make sense to dedicate all of these resources to Meteor Work?”

All of this work is happening today and is being funded, so that stays as it is. We’re not doing a financial transformation. The teams will just be planning and executing together. Everything else stays the same.

Question 2: Who is going to lead this initiative? Are we changing the management structure?

No, everyone reports to who they’re currently reporting to. We’re just going to have the teams plan and execute together. Aside from that everything will work as it’s working now.

Question 3: Does it make sense to have a new Release Train dedicated to Meteor? Does Meteor have enough work to pull in this many people? And what happens to the other work some of these people were doing?

We can think of this as a Meteor themed train as opposed to a train dedicated to Meteor. Everyone will continue to support what they’re supporting now unless it makes sense to shift their focus, in which case we will make sure we have coverage.

Question 4: But who’s going to pay for all this?

Question 5: How will the reporting structure change? 

Question 6: Does it make sense to dedicate all of these resources to Meteor?

Question 7….

Question 8….

Question 18….

Every week, over the course of the next 3 months, I fielded variations of the first 3 questions, but in the end, I got my train. How, then, did I spend my time during those 3 months?

Business Transformation

The business and management folks of this portion of the global marketing organization were very motivated to learn how best to use Agile to serve their stakeholders. I helped them understand how they could interact with and guide the work taking place by creating leadership, technical, and product scope cadences. These sessions, held on a regular cadence, would allow feedback to flow up and down the organization, and allow for ongoing course corrections. Beginning in late August, we created a calendar of events that would take us to a two day offsite business planning session. The opportunities and challenges we addressed were as follows:

Transform the core business team.

This was the group of people charged with ensuring Meteor was a success. They became my “change agents,” folks to be mentored to take the reins of the transformation.

• Activities
  • Training
  • Adapting to new roles & responsibilities
  • Establishing a Lean Portfolio Management structure

Adapt how we think about and structure our work

The current work structure could best be described as abject chaos. Marketers across the world submitted requests for new capabilities to support their local markets, only 40% of which would ever be built. Their ideas ranged from partially baked to ingredients spilled on the floor. The core Meteor group often chose which ideas to build based on whether they understood the request as much as whether it represented high value. The marketers for their part were completely in the dark about how ideas were chosen, where their ideas stood in the prioritization queue, and when they would be done. Creating a clear, transparent working process with frequent feedback loops was going to take a lot of work.

• Activities
  • Create an Agile work breakdown structure
    • Create a Definition of READY for Features and Capabilities
    • Provide marketers with a template as well as an example of a READY item
  • Familiarize all necessary marketers with the new process
  • Establish an objective prioritization model that focuses on the WHOLE using Value, Urgency, Risk/Opportunity, and Size (WSJF)
    • Focus on 
      • First: What’s best for the enterprise?
      • Second: What’s best for marketing?
      • Third: What’s best for my market?

Prioritizing the work for the coming year

We grouped the marketers by global region and time zone (Mexico and South America, Japan, Australia and China, etc.) and gave each of them a 2 hour overview of the new process including feedback about their submissions, and the promise that as we better understood our capacity to deliver, they would get accurate updates about where their requests were in the queue. We explained the idea of optimizing for the whole as opposed to their local markets, and gave them 2 weeks to get their submissions into a Definition of READY. For a coach, this is often done with a mixed feeling of hope and dread… will they have the foresight to do what's best for everyone, or cling to their individual needs?

After everyone had polished up their submissions, we began having prioritization sessions with the same geographical groups, hosted by the core Meteor team. Local marketers gave an overview of their requests, some discussion took place, then, using Planning Poker everyone cast their vote for the relative value and urgency, (risk and size would be done later by the tech experts). 

Everyone has favorite moments in their career and this was definitely one of mine. These types of interactions started happening:

“Wow, your idea is amazing, I have to admit it’s higher value than mine.”

“That would make a huge difference for your region, I’m ok to wait for my request.”

People who’s bonus depended on hitting certain KPIs were knowingly making things harder for themselves in the service of what would be objectively better for everyone involved. It turned out that they had never had this level of transparency into what their peers were doing, and when they got an opportunity to be involved in the process and decision making, they made the right call every time.

Prepare for the Business Planning session

Referred to as Pre-PI planning in SAFe, our objective was to create a roadmap for the next year. Even though we didn’t have teams with an established delivery history, we had architects and other SMEs available to make some educated guesses as to what was likely to work. Leaders were prepared and understood that any forecasts we made wouldn’t solidify for a few sprints. As many people were flying in from across the world, we booked a large presentation room at a prestigious hotel for the event.

• Readiness criteria
  • Work for the upcoming year is prioritized and meets the DoR (Definition of READY)
  • Everyone in attendance is aware of the new way of working, as well as how they need to individually contribute
  • Development team structure is established (we know our capacity at a high level)

The Business Planning session

The day was upon us and everyone was excited. Months of planning lead us to this point…, and as luck would have it, I was up all night with food poisoning. 

I subsisted on alternating between sipping on beef bouillon and tea for the next two days and somehow I made it through, but rather than describing the event, I’ll let these images speak for me.

The Cross-Organizational, Cross-Functional Agile Release Train

It was now December and, with a solid business roadmap for the upcoming year, it was time to turn our attention to the new teams. Everyone from New York flew into the offices where most of the teams were located. We spent the next week as follows:

Days 1 and 2 - Agile Training and Team Building

Days 3 and 4 - PI Planning

Day 5 - Execution Plan and Celebration!

There it was... we had our plan for the year. We had new cross-functional teams set up to collaborate in a new Agile working environment. We went into the new year full of hope and optimism.

When January rolled around and the work began in earnest, the teams went through the usual growing pains, but were able to get into “norming” sometime during the first PI. We established aligned cadences for the Team, Team of Teams, and Organization to make sure feedback flowed freely across all holons (organizational levels), and we were elegantly able to respond to changing conditions, both internally and externally. By the end of the year, the teams had boosted their throughput by 250% and their planned vs actual was at a solid 83%. Dozens of marketers who had been told their requests would have to wait until next year were having their requests pulled in early. The new Agile Release Train became the gem of the enterprise.

Although on the surface this appeared as a SAFe transformation, it was approaching what SAFe had to offer using our Integral Approach that made this critical success possible. Establishing clear Roles & Responsibilities, appropriately Scaling our Ceremonies,  and taking a Four Quadrant Perspective to our organizational timeline allowed me to surface challenges before they became problems, and take full advantage of the opportunities at the right time, with the right actions.

I’m proud of the business results we created, but what I’m more proud of are the relationships we created, the look on people’s faces as they realized work could actually be enjoyable. We changed the lives of hundreds of people over the course of those 18 months. They worked less hours, created closer bonds with each other, and delivered results that made them feel proud and connected to the impacts they created.

I am very grateful to everyone who suspended their disbelief and decided to take this leap with me.

With love and respect - Leor