Code Health Kaizen: Self-Organizing for Agile Improvement

For the last year, teams within an organization I have been working with have been taking team health surveys on a monthly basis. The survey invites teams to evaluate themselves on categories such as backlog health, continuous improvement, collaboration, and the release process.

Typically, the survey data is used in team retrospectives to focus on what is going well and what can be improved, as well as to view trends. A number of people have asked how we could use the data to tackle organization-wide issues that affect all teams. After some thought, I decided to engage a group of interested individuals to discuss how we could focus on one issue and improve.

The issue of code health was chosen for a few reasons:

• It consistently ranked in the bottom five categories in team surveys
• Code health is something that engineers have control over and can improve
• Leadership does not need to be involved in improvements, making them easier to adopt

We decided to schedule time for an open discussion and invited anyone who wanted to attend. I planned for the event by having a loose structure and some ideas but made sure to leave space for the participants to help set the agenda.

Brainstorming and Planning Actions

We held a one-hour discussion over lunch in order to minimize conflicts. About fifty people attended, which made the meeting standing room only.

I facilitated the discussion, and we started by talking about what everyone in the room wanted to get out of the session. After discussing goals, we documented them on a whiteboard wall.

Next, the group developed an agenda, which was also written on the wall. I wanted to be able to come back to the agenda generated by the group to show that this meeting was for them.

After creating the agenda, we had a brief discussion about what it means to have good code health. The group had strong opinions—some ideas piggybacked on others, and some led to disagreements, but one thing was sure: we could have had a great discussion for hours. 

Next, we used the Circles and Soup innovation game for retrospective analysis to identify what issues were in our control, what we could influence, and what we had to live with. People wrote ideas on sticky notes and grouped them, and then we talked about some of the higher-level themes.

Some of the back-and-forth discussion that followed led to ideas for actions, and a few people felt passionate and motivated enough to volunteer to own those actions. Others pointed out that code health should start at the team level, not with organizational initiatives, which was a fair point.

Near the end of the session, I asked the group what comes next. As in any retrospective, you don’t want a complaining session—you want to identify measurable actions to be worked on in an effort to make improvements. One engineer spoke up and said that we should get together again in a month to check in on our progress. I offered to own that action.

Before closing the session, I went back to the list of goals the group had come up with to see if we’d addressed everything. We didn’t get to all the items, but we did get through five of six.

Overall, the discussion went well, and it felt great to have several actions and specific owners for them. It was also nice knowing that people wanted to get back together and follow up. Despite differing viewpoints, this topic had sparked a great deal of interest.

Turning Ideas into Outcomes

There was a buzz about code health after the session, and it didn’t take long for people to start taking action. One group led a charge to roll out a new testing framework to all teams. An engineer started working to standardize the README files in all repositories. Another engineer contacted me about starting a book club for continuing education. Another group formed, calling themselves Engineering Education, with the goal of spreading engineering knowledge throughout the company and offering a forum for learning. There was an organic, bottom-up movement unfolding, and it was great to see.

During the original code health discussion, there was skepticism about how much leadership actually bought into the importance of code health. I knew from discussions with leadership that it was very important. I also knew from previous initiatives that bottom-up efforts can be strengthened by top-down support, so I worked with leadership to craft a message that demonstrated their support for healthy code.

After a couple of weeks, it was clear that the Engineering Education group was gaining steam. They had a Slack channel and weekly meetings. They organized tech talks with strong attendance and powerful discussions. They created a team spotlight, where a member of the Engineering Education group would interview a product development team and the information was sent out in an email. The content included a picture of the team, team member names, what they worked on, applications supported, languages and frameworks used, some challenges they faced, approaches to improving code quality, and what they could help other teams with.

When I attended an Engineering Education meeting, I was happy to see considerable attendance. The group had a backlog of items they went through, providing updates. Discussions followed about what could be done to move items forward and about new ideas.

After the month had passed, we had the follow-up session to discuss the progress of code health initiatives. It was decided that the Engineering Education group would lead the way. All the other initiatives had grouped under that umbrella, and it was a natural way for everyone to keep a pulse on what was happening and how to get involved.

Maintaining Momentum

The next steps for the group include promoting themselves (via word of mouth, internal newsletters, digital signage, and posters), getting involved with new hire orientation, and possibly creating courses for the company's continuing education program.

I really enjoyed watching the different groups and initiatives form and then ultimately come together in solidarity. To me, it demonstrated what can happen when people are passionate and have the autonomy to be self-directed. The team health survey simply provided data and insights. But those insights led to a conversation that motivated and empowered people to share, learn, and improve themselves, their teams, and the organization.