Pivoting at Speed to Scaled Agile and DevOps – Chapter 3

Chapter 3 - In the Engine Room

The old idiom “the devil’s in the details” couldn’t apply more to our initiative. We have six global development teams that were executing in waterfall that we’ve essentially restructured and told them to do agile. To catch up on how we got here see Chapter 1 and Chapter 2.

Sound like a recipe for disaster? It could very well be, but seeing that we’re at a position where we can only improve, the gamble may just pay off.

Coal Power before Steam

Remember the Integrated Delivery Teams from last time? We now have six IDTs each having their own set of outcomes to achieve. The outcomes are the discrete business capabilities from end-to-end potentially spanning multiple systems. This alone is a huge benefit in that we’ve removed the artificial barriers to cross-team communication and, at the same time, given a group of people a common mission that if they meet, will demonstrate complete business capability and value. But how do we actually get to a state where we can execute?

The first thing we did was to use an old school exercise of taking whiteboards and 3x5 cards for each of the business capabilities. Each business capability was given to one IDT (remember that the IDTs were created to be able to address end-to-end business capabilities). Each IDT then had the mission to size the effort for the capabilities in terms of t-shirts: Small, Medium, and Large. Small meant less than one sprint got ½ of a 3x5; medium was one sprint and got one 3x5; larger meant two sprints and got 2 3x5 cards; anything greater than larger had to be broken down to sub-units to make sure the effort fit into one of the three sizes. The teams then mapped the effort over a fixed timeline in terms of business value provided by the business lead on the IDT.

What did this planning activity accomplish? A number of important things that we weren’t able to get when we used the waterfall approach:

• Upfront planning that accounts for functional business capabilities. This is different from where we break estimations down by piece of code or even business application. Because this was primarily an integration project, having a cross-application IDT allowed planning for an actual end-to-end business capability across systems and awareness of when it would be completed.
• Understanding of the IDTs to the work they would have to do. These are the teams that would actually implement the business capabilities. They learn about these upfront and start to understand dependencies within their scope.
• Visibility to the business stakeholders of key requirements that were missing. It's hard to estimate with a lack of understanding of requirements. We didn’t learn all the details in planning, but we were able to have business stakeholders identify where they needed to go back and get more detail to reign in a high estimate. The planning also helped business stakeholders more clearly articulate which capabilities were required versus the nice-to-haves.
• Commitment from the IDTs. They were the ones saying how long they thought it would take to complete the work as opposed to a random top-down estimation approach.
• A solid idea of the overall realistic timeline. Remember how we found out too late that we weren’t going to make a key deadline. This planning approach allowed us to provide executives with a realistic timeline that balanced speed with business capabilities while not needing all of the detailed requirements up front.

Beginners Luck

Of course, starting off on doing the work to implement the business capability is only part of the equation. We have an entirely new team that’s unfamiliar with working with each other. Oh- and add to it the fact that 75% of the team hasn’t worked with an agile development approach.

To address the required learning, a sizable portion of Sprint 0 was dedicated to educating both onshore and offshore resources on the nuances of agile. Here we focused on both the similarities and differences from how they were working before.  Some examples:

• Keep your actual and to-do numbers up to date. This is key to ensuring that the entire team has visibility into current progress and can adjust if somethings not going the way that it should. Remember our radar from Chapter 1? We want to be sure that we don’t lose it. The user story and task based tracking allows us to have the right level of visibility and course correct.
• Document ONLY what you need. The elimination of the heavy cycle of writing, reviewing, correcting and approving elephantine documentation that, in the end, offered little value to the organization, was a significant behavior change. This didn’t mean no documentation. What it did mean was doing the right amount of documentation in the right format so that there was clarity on how business capability was being implemented. Key to this was iterating as business requirements were uncovered during the development. This allowed developers to develop, elicit the nuances of the business requirements, implement, and keep moving rather than attempt to uncover all of the requirements before starting any development.
• The Stand-Up. The spontaneous interactions we experienced between the disparate teams during the integrated test cycle was great. With the daily stand-up of the IDT, we formalized this interaction and communication. Clear and regular communication from the members of the IDT - both business members and technical members allows them to eliminate bottlenecks and move quickly to get the job done.

Come Together

Imagine each IDT is a separate engine on our ship. Each of the six engines contributes overall to our ship moving in the direction we want. However, there needs to be communication between the engine operators to ensure that everyone is moving in the same direction and to make adjustments when they aren’t.

This is where the Stand-Up-of-Stand-Ups (suosu) comes into play. A thrice weekly sync of the key players from each IDT AND the core program management staff (program manager, project managers, business lead, solution architect, etc). Why have all of these other players involved? The suosu is the fastest way to truly understand the impacts of interdependencies to the program and then to make the necessary adjustments. Without it, you are reacting rather than being proactive.

Here are some examples where we were able to make real-time adjustments to ensure success:

• Moving user stories from one IDT to another when there looked like the one team might not have the resources to complete it.
• Creating another IDT from existing resources to provide focus to a set of critical business capabilities that had originally appeared simpler.
• De-prioritizing some business capabilities in favor of others.

Now we have the engines ready to fire to drive us forward in the way that (we think) enables visibility (the radar), transparency, and ultimately success. Next time we’ll talk about how we handle the complexities of a globally distributed team. Think your team needs to all be co-located to do agile. Our next chapter may have you thinking differently.

#guerrilla_ea