8 Practical Steps to Guide a Successful Transformation

Brian Link
Practical Agilist
Published in
5 min readFeb 6, 2019
Turning Torso by Bert Kaufmann under CC BY-NC 2.0

If you have an IT or Technology division over a few hundred people, there’s a good chance you’re involved in some kind of agile transformation. And still in 2019, this stuff is not easy. There are many frameworks to choose from, consultants with conflicting opinions, age-old cultural challenges to overcome and unfortunately no simple guide to turn to. There are also many books to read on the topic, but the reality of any agile transformation is that your approach is going to be entirely custom, because every company has very different challenges.

As I’ve been studying and thinking about agile transformations, however, I think I’ve come up with a few obvious things you can use to guide your progress. This list isn’t complete, but if you do these things well, you are definitely on the right path. I offer them below in a logical order, should you have no idea in which order to start. But, as I said, your company may require an entirely different sequence and strategy to accomplish these things.

Agile Community of Practice

I’ve blogged about this before. And it’s a relatively simple thing to do, but it is very effective at breaking down barriers and creating serendipity. People will meet and learn from each other. If done right, it’s a safe place to ask questions, every voice is heard and anyone can instigate change in this environment. Here’s how I suggest you start an Agile Community of Practice.

Agile Foundation

It’d be nearly impossible to make progress in an agile transformation if you’ve not yet established some level of success at a team level being agile. Many organizations start with Scrum as their agile training wheels. Training and coaching are often required for teams to embrace the mindset. And your company definitely needs some level of support from middle and upper technology management in order to drive team behaviors, an iterative mindset, XP and DevOps skills and offering trust to the teams to build the products they’ve been asked to work on. There are many ways to get started with agile basics, but my book addresses some of the objections you may hear.

Stable Autonomous Teams

Along with the agile basics is a very important concept of longstanding teams. Teams that have established psychological safety work better together and produce better products. Let teams form their own mini-cultures and provide them the space and support they need through servant leadership to thrive. You can run the work through the teams and build a productive organization but first you need great teams. Leadership should work hard to put ALL required skills on-team and offer trust first to see results.

Product Management

A critical ingredient to success to any agile environment, arguably well before a transformation is begun, is to establish a centralized Product function. Product Managers are the glue between what is often called “the business” and “technology”. (Instead, we should all say the words out loud, “we are all the business”. Thanks, I will keep reminding everyone of this) Put a Product Manager on every team, have them work directly with the team every day and actively prioritize the backlog in conjunction with the technology requirements to build healthy backlogs that will maximize customer value, build emergent architecture and manage technical debt.

Servant Leadership

Our friendly middle managers are often neglected in agile transformations. They need training and coaching too. While they should retain many responsibilities of HR/career related topics and risk management of the solutions in general, they should no longer be telling teams or people what to do, which is often the hardest part. All leaders in title or in spirit should adopt a servant leadership mindset and think how they can best support the team, remove obstacles and create the right space and environment for the product teams to thrive.

Agile at Scale

Some may argue that no one ever needs to scale because products can be broken down too and small teams are the best way to be agile. However, there are many real world examples where multiple teams will need to share a common backlog. If you must adopt a framework, be sure you are allowing the teams to innovate and adapt the processes to their own needs, solving challenges related to the logistics of communicating between teams of teams, cross-dependencies of technical topics, test-driven and behavior driven approaches to XP and DevOps, and hopefully finding a path to maturity in continuous integration and continuous delivery.

Portfolio Management

For the entire technology division to focus on results, there must first be visibility and transparency to what all of the teams are doing. There should also be an effort to monitor and limit the degree to which critically shared resources are leveraged (architects, scrum masters, delivery managers, UX, etc.) Ideally, there is one path to funding any technical team to work on a product or project and some level of lean business case and senior leadership approval process be put in place. This process should be light and fast so that critical high level decisions can be made at any moment to shift people and resources to where they are needed most.

Agile Center of Excellence

As critical decisions are made on the teams, or great questions are surfaced in a Community of Practice, there should be a way to codify the recommended approaches and decisions about how the company prefers to build software. The most knowledgeable and respected agilists in the organization who are connected closely enough to the teams should become the leaders in an Agile Center of Excellence to help document and share this knowledge. I like to call it light governance, because forcing or making agile prescriptive rarely works. But offering strong recommendations with the support to actively work with the teams to coach and train them on the recommended approaches tends to work very well.

“Agile Misconceptions: Unlearn the Myths to Learn the Mindset”

Free Book

About the Author: Brian Link is the author of AgileMisconceptions.com (also available on Amazon) and the owner of Practical Agilist, LLC. Brian provides leadership and coaching services as an Agile Coach at LeanDog. Follow Brian on Twitter @blinkdaddy or LinkedIn, and subscribe to his newsletter.

--

--

Brian Link
Practical Agilist

Enterprise Agile Coach at Practical Agilist. Writes about product, agile mindset, leadership, business agility, transformations, scaling and all things agile.