Agile Transformation

Challenge

Being an engineer, I was intimately familiar with agile methodologies and their immense benefits to software development. Within my own development teams, we practiced a variety of agile rituals. On my product teams, we were big believers in the Scrum framework and reaped all the benefits it had to offer. After years of company growth and contraction, individual competencies had picked up some well-intentioned, but inefficient work flows and processes. So, I needed to take a 30 year old agency's work flow and transform it into a lean, agile, team-based environment. Seems easy enough, right?

Solution

It all started with education and overcoming a common misconception that agile is "a tech thing". Throughout my years of process improvement, I read no less than a dozen books on agile methodologies and business process, but they were all quite "in the weeds." I needed something that I could share with executives and non-technical leads to help them see how agile could work in any business setting. Jeff Sutherland's Scrum: The Art of Doing Twice the Work in Half the Time proved to strike the right balance of compelling real-world examples written for business leaders. In the book, Sutherland argues that Scrum is one of the reasons why productivity gains of as much as 1200% have been realized by businesses in every industry. I quickly circulated the book to my peers and within a month, Scrum was the newest buzz of the office.

I had the right believers in my corner, but a complex change management task and business process transformation ahead of me. I was convinced that if a technology leader was heading up the charge to change the way the entire business operates, it was likely that the sticky perception that agile is a "tech thing" would amplify any resistance to change that existed. Everyone wanted change, but not many wanted to change. In order to build upon laying the groundwork for transformation, I brought in an outside expert to assess or current work flow. He interview key individuals and teams in the organization and presented his findings back to me and my peers. The message was clear that we needed an overhaul. Alas, the complexities of our clients' industry proved to be an obstacle to simply applying the same Scrum framework that worked so well for my product teams to all of our work. We needed to invent something unique. A process that we could call our own and worked in our idiosyncratic business. This approach isn't uncommon. In fact, an estimated 75% of companies that adopt agile, make modifications to existing frameworks to make it work for them.

To know your future you must know your past” George Santayana

Being a rapidly moving company, no end-to-end mapping of our work flows even existed. Of course, each competency had process documentation, but not a holistic view of how projects got done. This was a problem. How could we possibly change our future without knowing our past? So we pulled together teams that were intimately familiar with the project work and mapped out existing work flows. This was a fascinating exercise that, in order to save pixels, I won't expound on here. At the end of this phase, we had a well documented picture of how our teams were working, and we were all set to move on to the next phase: improving the way we work.

Next, I created an advisory team, with leaders from every competency, to help map our future. The team worked hard to apply their best thinking and ultimately created a draft of our future work flow. Not surprisingly, the output was even more complex than what we already hard.

We needed a flexible framework to do work right, not a brittle and prescriptive step-by-step work flow. After educating the team on a few of the most popular agile methodologies, and drafting a example approach to how we might get to where we needed to go, we landed on a solution that was simple, flexible, and most importantly improved not only the speed to deliver work, but also the quality. Not to mention, more accountability, better transparency, and far less bureaucracy.