Funny retro swimmer by the lake, at the sunset with copy space

If You Wait to Start Your Agile Initiative, You May Never Actually Start.

If you’re waiting for the perfect time to start an agile initiative or to launch a pilot program, you may be waiting quite for a while. You won’t always have the time/space/support or even all the “right people” for big kickoffs or to “officially start” for your program. When waiting on the “boat dock of perfect,” oftentimes opportunity sails right by, piña coladas in the blender.

Such was the case with a team I’m working with at a large government organization. They are one of the first agile pilots in the organization, and interestingly enough, they’re not IT. The start date kept getting pushed back because someone was on vacation. Then a new job posting was waiting to be filled. Then we were onboarding a new contractor. Then it bled into the 4th of July holiday. Then. Then. Then. You get the picture. We came to realize there would never be a perfect time to have an official kick off, training, or baseline assessment. This group of five incredibly capable individuals was eager to start and didn’t want to wait. So, we started.

Make Sense of the Chaos

In realizing there may never be a perfect time to start your agile initiative (hell, you may not even give a damn about an agile initiative, but know in your gut that your team can perform better), accept the fact that starting could be a little messy. There may not be an opportunity for the team to take a Fundamentals of Agile class or make a formal transition plan. You’re just going to jump in and start untangling the hairball of workstreams, roles, and Work in Progress (WIP).

One of the best ways–not the only way– to untangle the hairball is to start visualizing the work. A physical visualization creates the ability for a team to become aware of their norms, processes, and communication patterns. It’s also a powerful step toward self awareness, team awareness, and team empowerment. Often times, just understanding the team’s workflow, group dynamics, communication channels, and current team “norms” helps to level set “current state.” It creates a single lens that everyone can look through and forms a common ground. In other words, a baseline for perspective.

In short, visualization creates data points, data points create awareness, and awareness creates the ability to make educated, data-driven decisions from a similar perspective.

1. Document the Doing

Throw a Scrum or Kanban board on the wall.Have each team member write on a Post-it each individual task they’re doing and put it in the DOING column. (Don’t worry about the TO DO or DONE columns at this point.) Pretty soon, each team member will have a pretty good picture of all the things they’re juggling, as well as a good idea of what everyone else is doing, too.

For the team that I am currently working with, there wasn’t a huge “documentation of DOING event.” We just started by having daily stand- ups. Each day, as people talked about what they were doing, we would put Post-Its on the board, and pretty soon we were able to visualize all the work the team was doing.

This visualization exercise was especially beneficial because we knew the team was doing work, but we didn’t necessarily know WHO did WHAT work. As the Post-Its piled up, the WHAT and the WHO became clear. (Naturally, new stuff started popping up, so we started filling in the TO DO column.)

2. Understand the Process

Seeing this big picture–actually seeing it physically in front of you– will give you some very, very powerful information. Early on, through visualizing the work, our team was able to understand the workflow. We were able to understand the different workstreams (where the work was coming from), how work was distributed (by a single person hub spoke model), and how people got pigeonholed into work types (skill-centric roles).

It immediately became apparent that Work in Progress (WIP) was off the charts, and context switching (switching from one type of work to another) was out of control. One team member was switching across 8 workstreams on a daily basis! (How can someone focus with constant change?!) Having a better idea of workflow also allowed us to see who was making decisions and have informed conversations about work prioritization.

3. Make the Change

You’ve talked about it. You’ve visualized it. Now, armed with your newfound knowledge, start making hard decisions and incremental changes.

Incremental Change #1

As a team, we knew we wanted to eliminate the hub and spoke model of work distribution. Our goal was two fold: to create an environment where people committed to work they are interested in and capable of, and to take the administrative duties of assigning work away for anyone individual. We adopted Kanban, a pull system for workflow optimization.

Incremental Change #2

In implementing the pull system, we quickly learned that when someone became available, due to their respective specialized skill set, they were not always equipped to take the next highest-priority piece of work. We knew we couldn’t completely eliminate this from happening, but we knew we could make it a whole lot better than it was. This lead to the cross-training, “paired programming” initiative. As a non-IT department, we weren’t programming, but the idea remains the same: work in pairs to not only get the job done, but to create a cross-training learning experience.

Incremental Change #3

Similarly, we strove to greatly reduce WIP and find the sweet spot of what we could handle as a team. We found it helpful to document WIP at every stand-up. Dropping what we had already started wasn’t an option. So, our goal was to continue to shrink the amount of work in the DOING column. Simultaneously, we were creating disciplined behaviors. If something wasn’t ready to be worked on, we were to leave in the TO DO column until the last (ir)responsible moment.

Incremental Change #4

To help with understanding the workstreams (some being more important or time sensitive than others), we chose a color for each one and created a legend in the top right corner of our board . For example, blue for Quarterly Report, yellow for Data Science work. Each of our workflows and all its associated tasks would match the color of workstream they were related to. This not only served as a reminder for the team, but also provided at-a-glance information for anyone walking by outside of the delivery team.

On the same note, another trick we adopted was showing our workstream legend with the highest priority workstream on top. This would help keep us honest on our day to day decisions. When the team was prioritizing their work we could constantly compare our decisions to the workstream prioritization and make sure we were spending our time on the right things.

Don’t wait. Just start!

If you’re waiting for the perfect moment to launch your agile initiative, don’t. Just jump in. Your team should find it immensely helpful to visualize the work and harness the power of awareness. The picture that emerges will spark conversation, and more importantly, data-based decisions for change. Your team will feel informed and empowered to create a better way of working together. Plus, they’ll create a better delivery model for your customers. (And it’s all about the customer!)

If our team had waited for the perfect time to start, we’d still be waiting. Since we did the very first stand-up, a person changed positions within the team; we added a contractor to the team; and we’re in the process of onboarding one more person. Though not the ideal situation, we’ve improved by leaps and bounds. Now, when we onboard new people there will be a new baseline instead of the old way of doing things. Onward bound!

By: Darren Hoevel

Agile Charm 2020

Be sure to catch Darren Hoevel at Agile Charm in Baltimore, MD on February 13, 2020!

The World Needs Brave Leaders!

About Agile Charm

Don’t wait for the perfect time. Start by visualizing the work.

If You Wait to Start Your Agile Initiative, You May Never Actually Start.