Being an Agile Team of Agile Leaders

When introducing agile, it is easy for management to expect their teams to change while not truly understanding what this change means on a day-to-day practical level. Leaders run the risk of confusing their understanding of the theory with a genuine appreciation of what it means to operate as an agile team. I often see this manifested in the traditional project plan, complete with a Gantt chart that outlines how an organisation will transition to agile.

 

As part of establishing the EDW Release Train, our coach encouraged my new leadership team to operate as an agile team. At first, we mobilised around preparing for our first PI Planning event. We had a Kanban board with all the tasks that we needed to complete and daily stand-ups, but we didn’t have the discipline to make the time to action the tasks! To this day our coach loves to tell the story of our zero-velocity first iteration! Personally, it never ceases to amaze me how difficult it is to get agile leaders to operate as an agile team. It would seem we were much better at instructing others on how to be agile than we were at walking the talk!

 

Despite our first proper PI Planning event being abandoned in favour of Unity Day and our dismal performance as an agile team, we decided to keep the wall, broadening its focus to continuous improvement of the EDW Release Train. By this time, the Leffingwell Book Club was well established, and many of our early improvement ideas came from the rich debates we had in bookclub. As time passed, new ideas started coming from all directions, and it was not long before we were drowning in a “pit of fantastic ideas”.

 

Making time for improvement activities was an ongoing battle. Day after day, the wall would stay static. One of my team even renamed our wall the EDW Release Train Sporadic Improvement wall. I tried to help my team make time by scouring their calendars, looking for meetings they could decline or delegate. We tried setting up a dedicated time to focus on improvement activities. We even appointed a Scrum Master to nag us. Not to say we were achieving nothing, we were definitely making small improvements here and there, but we were all frustrated by our inability to get cards across the wall in a timely fashion.

 

Our resident lean enthusiast Wayne had insisted on limiting WIP from the outset. For the rest of us, with our traditional mindsets focusing on maximising utilisation, this just made no sense. I clearly remember the “light bulb” moment in the midst of a fierce debate about the stupidity of this approach. All I could see was the specialist skills each of my leaders contributed to the team. Our coach was quick to explain how fewer cards in play and a WIP limit stopping new cards coming into play would force my direct reports to team. The only way anyone could progress their priority cards from the backlog was by supporting their teammates in progressing in play cards to done.

 

Each retrospective resulted in passionate debate about how we needed to change the wall to enable flow. The team was convinced that the WIP limit was the reason cards weren't moving, and the debate raged on for weeks. In the end, rather than teaming to move cards, some of my direct reports created their own “rogue” continuous improvement walls in their team areas. It was like an underground movement to enable them to progress their priority cards that would otherwise be blocked by those stuck in WIP. By this time, I was going out of my head with frustration.

 

Before heading off to the U.S. for my first Agile speaking engagement, I left Wayne with the task of getting all improvement activity surfaced on the leadership continuous improvement wall. Given I was missing in action, Wayne decided to add their own twist to this task and removed the WIP limits completely "to help the team learn the hard way". I returned to Melbourne to find every inch of the 6-foot "doing" column filled with cards. It took us months to clear the board, and when we did, we reintroduced WIP limits and never looked back!

 

I would love to be able to tell you that once we learnt about the value of limiting WIP, we became a true agile team, but that would be dishonest. The truth is that we continued to stumble on so many of the lean and agile basics that we were so quick to preach to the delivery teams. We struggled with batch size, prioritisation, the definition of done, demonstrating progress, collaborating with our customers (the teams) and even basic face-to-face communication. Month after month, we would reflect on the process, and every so often, a penny would drop, and we would see the answers to our problems were right under our noses in the lean and agile principles.

 

Perhaps the most frustrating of these lessons was learning the art of simplicity. I remember after I read Extreme Programming Explained, I wrote “What is the simplest thing that could possibly work?" on a sheet of paper and stuck it on the wall above the continuous improvement kanban. This worked for a short while, mainly when it came to the size and complexity of an improvement initiative. Strangely it didn’t once stop us from overengineering our kanban wall and associated processes. At one stage, we had investment themes, WSJF prioritisation and everything loaded in Rally for tracking and reporting purposes. In another stroke of genius, we managed to intermingle the leadership continuous improvement effort with our end-of-iteration “Bubble Ups” and our specialist chapters (inspired by Henrik Kniberg and Anders Ivarsson's paper on Scaling Agile @ Spotify).

 

Two years on, I can tell you it is "the simplest possible thing" that eventually made this work. Today my office (which seems to double as a rec room for my leadership team) has two very simple walls. The continuous improvement wall visualises the big ticket items that we will lead out on behalf of the Release Train. Hand-written cards with only a few words to indicate the essence of the idea and a simple “Plan, Do, Check, Spanked” kanban board (spanked being our version of done). The second wall is Leadership Ops. Filled with post-its that represent the tasks we are working on from a day-to-day operational perspective, designed to help us communicate our focus for the day ahead and debate priorities. The boards are maintained through a combination of our daily leadership stand up and weekly lean coffees.

 

Getting leaders to team is equally if not more challenging than getting development teams to gel. After two years as an agile team of leaders, our “ba” still pales in comparison to that of the feature teams we work with. We have a lot of fun, but our effectiveness is still patchy. Rather than deterring me, I have found our struggles to be all the motivation I need to persevere with this approach. There is no doubt in my mind that through doing, we are learning and that learning is making us better leaders. In the words of W. Edwards Deming: "To manage one must lead. To lead, one must understand the work that he and his people are responsible for."