Using Agile to Lead Your Agile Transformation

I'm amazed by how often the act of going agile is treated as if it were the rollout of an enterprisewide Windows upgrade. I once worked with a client who had been planning their transformation for more than six months before I came on board. It was another six weeks until we got to any kind of doing.

Let's use a waterfall approach to go agile. Yeah, that's going to work out great.

Even worse than an organization approaching agile in a waterfall fashion is when an agile consulting company approaches its clients with a formulaic process. I've seen consulting companies give a detailed "engagement plan" that dictates everything they will do, down to the individual day or even half-day.

We ask our teams to be open to change, to be flexible, to be agile. Then we roll out a transformation using a paint-by-numbers instruction book, and we wonder why we fail.

We have to move away from a prescriptive playbook and toward a more responsive transformation model. Looking back at how I'd been successful in all the transformations and organizations I’ve worked in since I began using agile, I find that I was successful at agile transformations by just trying to be more agile. More precisely, I adopted the concepts of Scrumban.

Scrumban: A Flexible Plan

Scrumban is a melding of the Scrum iteration framework with the responsive, flow-based system of kanban. It's useful for teams that value some measure of timeboxing and planning but still have enough churn to need the ability to respond inside the span of an iteration.

My version of Scrumban came about from a desire to have my week planned out while recognizing that any plans I make are likely to be highly volatile. It started as a simple coping mechanism, when I was looking for my first agile job back in 2009, and grew to be how I drove every aspect of my life.

I use Scrumban to plan out my weekly work, run all my training workshops, do all my job hunting and lead generation, and every time I manage an agile transformation. In my personal life, I also use Scrumban to keep track of the household "honey-do" list, and I even used it when I moved from California to Washington with less than four weeks to plan and pack.

The mechanics are fairly simple. Let's use my weekly agile coaching as an example.

• On Monday morning I start by reviewing my previous week, paying particular attention to how much of the work I got done the week before was planned work and how much was interruption.
• Knowing my planned and unplanned "velocity," I can then look at how much planned work I should take on for this week's sprint.
• I then pull from a backlog of existing work as well as consult my calendar and coaching notes to see what I want to try to get done in the week.
• I do a rough estimation, both of the value and the level of effort.
• I pull in a backlog of prioritized work and mark it so I know it was part of my planned work.
• As new priorities come in (they always do), I look at my existing backlog and decide where the new priority fits. If it has to be done this week, I move a planned item down or even out of the backlog.
• Rinse and repeat.

Make It Visible: A Key to Success

Agile is all about transparency. As an agile coach, I need to practice that even more than others. Not only am I setting an example, it also makes my work visible to the teams, customers, and management. On my first day working with a client, one of the first backlog items I always have is to set up my task board.

Here's an example of a day-one board from a past client:

I usually include short explanations of each of my workflow states.

• Backlog: "Everything that needs doing"
• In Progress: "What I’m Working on Right Now"
• In Review: "You are my customer. Often that means I'm not done until you review"
• Waiting: "Collaboration sometimes means many hands. Sometimes I have to wait while other people do"
• Done: "Time to celebrate"

I also include work-in-progress (WIP) limits on each workflow state and usually have a note off to the side explaining what WIP is.

Keeping Track of Work

At the end of every agile coaching sprint I take the done work and record it. The picture below shows two years of finished backlog. The top book shows my first week as a full time coach at AOL. The bottom book is a snapshot from my most recent client. You'll see I evolved my tracking over time. I now note the stories and points I planned, the stories and points I completed, and the planned stories and points I completed (the number in parentheses).

Having all this detailed information (I also have Trello data going back to 2011) lets me reflect and learn from my past. This allows my new engagements to be that more successful. I can see what plans worked, what didn't, what took a long time, and what was a lot easier than I expected.

The following photo is another step in both transparency and understanding of what I can accomplish. It's a week-by-week track of my "velocity" when I worked at AOL. This was posted on the wall right next to the task board, where anyone could see it.

Scaling Up: One Coach to Many Coaches

What happens when one coach becomes two, three, or more? How do you scale up your agile coaching effort when there is now more than one cook in the kitchen? The same way we coach teams: by using agile.

Fellow agilist William Rowden has a simple logic he applies: Two people can have a conversation, three people need to start coordinating, and four people is a team.

When two coaches are working on the same transformation, pairing is key. With only two coaches, the organization or client is going to expect you to be in sync, and the easiest way to do this is to sit next to each other, talk constantly through the day, and make your work highly visible. While you may still have your own task boards and personal backlogs, you will also have a shared backlog you both pull from to meet the needs of the transformation. 

When you grow to three coaches, communication becomes a key focus. You can't be pairing (tripling?) all the time; you'll probably be with different teams and stakeholders during the day. A daily standup becomes essential at this stage. It's also when you want to start considering a shared task board. There are probably still going to be a lot of individual tasks right now, but the point is visibility. When Bob isn't around, I can look at the task board and see that Bob is in another building meeting with a new team.

When you get to four people, you've stepped well and truly into team dynamics. It’s time to pick a framework and use it. I've seen Scrum, Scrumban, and kanban all work here. My personal preference is to start how I start with teams, with Scrum, and then evolve quickly as the team and transformation progress. Someone is the product owner and responsible for the transformation backlog. And while it might seem like a team of agile coaches doesn't need a ScrumMaster, you'd be surprised. Even the best facilitators need a facilitator when you get to the team dynamics stage.

Work comes in two flavors: transformation backlog and coaches work. The transformation backlog is owned by the team and maintained by the transformation product owner. Coach work is made up of the day-to-day work a coach does up to and including things like expense reports.

Tracking the work in a visible fashion is critical. A physical task board is key if there are two or more coaches in one location. Even when spread across a multi-building campus, having a single task board creates an anchor for the team.

This is part of a task board at a multi-coach engagement I worked on. The dots have people's initials, so you know who is working on what. This just represents the User Story and Task columns. To the right of this were the WIP, Blocked, Review, and Done columns.

Even when I work multi-coach engagements, I still keep my own physical board. It is made up of duplicates of tasks from the team board as well as my coaches work.

Tools to Make Work Visible and Accessible

Even with a partially distributed team, I advise using physical boards and then video conferencing for remote people. So it's no surprise I do the same with my coach's Scrumban board—it goes back to the mantra "Coach what you coach.”

Due to the pesky detractor of a physical board only being in one spot, I also use an electronic board. Unless I'm in a 100 percent fixed location, I always mirror my board to an online tool. When you start adding in more coaches, locations, or travel, it becomes even more important.

At a multi-coach engagement there were coaches on different floors and buildings, which led us to needing a solution for remote access. Instead of a tool, we went low-tech and posted a picture of the board to Slack regularly. Moving to an electronic tool may have given us some added benefit, but it also would have probably led to more remote standup attendance instead of everyone making the effort to meet in person once a day.

Use Agile to Drive Agile

An agile transformation is disruptive enough on its own. If you try to layer in some custom consulting playbook, off-the-cuff consulting “process,” or anything that looks like an old waterfall rollout, you’re going to make the path even more difficult. Being agile from the start is an effective approach to working with the frequently changing requirements you’re sure to have. Why not use the agile transformation as your first opportunity to be agile?