The Chess Moves of an Agile Transformation

I love games like chess.

I say “like chess” because my first and one true love will always be the game Go. I was on a flight a few years ago, playing Go on my phone when I noticed the gentlemen next to me was not only playing chess on his phone – he was using a sophisticated chess training app. After a rich conversation about each game, I decided it was time for me to really learn the game of chess. Since then, I’ve used the app he recommended, and have played thousands of games, including many against that very gentleman I met on the plane. It’s been a humbling learning experience that ultimately made me a better player of both games.

Over the past year and half, I’ve been a part of a Sendero team that is working with a large utilities holdings company to “change the game they play”. In this instance, it’s a transition from being an organization who delivered work through a Waterfall methodology, where work is divided into dependent and sequential phases, to an Agile methodology.

When utilizing Agile, it’s important to set yourself up for success – something we’ve had quite a bit of practice in over the past few years. What follows below is largely advice and lessons learned regarding the “game” of Agile transformations.

If you change the rules, it’s not chess

One of the most common mistakes we’ve observed as companies tackle incorporating Agile into their business is to cherry pick aspects of Agile to incorporate into their existing processes. This isn’t necessarily a bad thing – but it’s not Agile. I affectionately call this approach “Wagile” (Waterfall + Agile); for example, while running a Waterfall project you may decide to deliver value iteratively (e.g., multiple go-lives or phases). You may also decide to focus your development efforts into sprints. Again, not necessarily a bad idea. But, this process doesn’t provide any meaningful information as to whether or not Agile is right for your organization. If you play chess with different rules, do you know if you’re any good at chess? To capture these insights with regards to Agile, your best approach will be to commit to running an effort(s) end-to-end totally Agile.

Expect to lose a lot of games initially but learn a lot

Prior to committing to a full transformation as an organization, I’d start by creating a few truly cross functional teams – ones that have the skills and are empowered to make decisions needed to deliver a project, product, or service. Train them on Agile, ensure you have certified Scrum Masters or Agile Coaches. Most importantly, expect them to fail initially. I lost an absurd amount of chess games before I really “saw the game”. Give the team that grace initially when they’re learning a whole new game, as they will likely become your subject matter experts when you scale Agile within your organization.

Additionally, and equally important, this control group will enable you to figure out how the transformation will have impacts across the organization. How do you want Accounting & Finance to handle an Agile team versus a “standard project team”? How does an Agile team “roll-up” into existing Governing, Compliance, Strategic Planning processes? The list goes on. I guarantee you it’s much better to figure this out on a small scale.

Know your Elo rating

The Elo rating system is an elegant way to access the relative skill of a chess player and is a system that’s been broadly adopted in all sorts of areas. Without knowing my Elo rating, I may think I’m an exceptional chess player. Turns out I’m marginally above average. It’s an essential reality check. Knowing where I am allows me to appreciate the chasm that exists between me and a Grand Master. If I were serious about becoming a Grand Master, knowing my rating gives me sense of what it would take to achieve my goal.

One of the aspects of Agile that can be jarring is the almost complete transparency that exists when assessing a team’s or team members’ performance. The work a developer committed to in a sprint either got done or it didn’t. The number of story points a team committed to in Sprint Planning were completed or they were not. A team’s velocity is increasing or it isn’t. There’s no hiding it – it’s all on the Kanban board for everyone to see.

The important point here is that an organization needs to cultivate an environment where people feel comfortable with this transparent view of performance, otherwise teams will be incentivized to “game the process”. Under committing, scoring cards based on achieving a metric, inflating their estimations to match the point total of another team, etc..

Additionally, it can be tempting to allow teams to come up with individual scoring systems and metrics because “every team is unique”. I’d urge caution here, as you scale agile across an organization there is an incredible amount of value in being able to talk apples-to-apples when discussing the efforts and performance across all teams.

Very few players excel at playing multiple games simultaneously

Sure, people like Magnus Carolsen exist. He can play a dozen people in timed games blindfolded, win every game, and then write down every move of every game when he’s done. Must be nice!

Recognizing that very few people in the world are capable of such feats, organizations should really consider how many Agile teams they assign to any one resource. A Product Owner, Scrum Master, or Developer. It can be cost prohibitive to keep everyone to a single team certainly. But, don’t forget to also weigh the costs of the constant context switching, schedule conflicts, and competing priorities that being on multiple teams introduces.

You can still play other games, and that’s okay

Oftentimes diehard Agile folks argue Agile makes everything better. From my point a view – and as practical matter – don’t force yourself into a one option approach. If you’ve run certain kinds of projects or teams a certain way, and they have a ton of success, let them continue. Create clear boundaries, and avoid making teams “Wagile”. Additionally, define those things that every project must provide to a Project Management Office or “Leadership”. Ensure you have processes and controls in place such that you can still measure KPIs regardless of delivery method.

What if in a tournament every game affected the outcome of every other game?

This is where my chess metaphor breaks down. Organizations are complicated systems with an incredible amount of interdependency. As you scale Agile in your organization, one of the greatest challenges to overcome is how to handle work across business units and teams. Another challenge is ensuring that teams don’t prevent one another from making progress.

What has worked well for my current client is adopting a process they call “Big Room Planning” – a “Scrum of Scrums” so to speak. Teams populate a Kanban board visible to the entire organization where they lay out their vision of what’s to be delivered by their team over the next quarter, as well as put tasks on each other’s boards when they need another team to do something for them. In these monthly Big Room Planning sessions, teams review one another’s boards, commit to supporting other teams, or have essential priorities setting discussions when they can’t fulfill the ask of another team. This takes a lot of effort from a lot of people, and the effectiveness of Big Room Planning is directly linked to the effort teams put into maintaining their boards, understanding what’s going on across the organization, and having leaders with a vision and the ability to make a priority decision quickly.

At the risk of sounding cliché, it’s important to remember that an Agile transformation is a journey. Anything involving fundamentally changing the way you think about work, deliver work, and work together takes time and a lot of practice.

I can tell you from my experience, in the same way I experience awe at the beauty and endless depths of games like chess or Go, I’ve experienced that same awe with Agile.

I guess the question you have to answer now is, do you want to be a student of the game?

By Scott Simari