Confluence was a mess. Our documentation felt outdated, hard to navigate, and unreliable. Rather than scrap everything and start over, I decided to try something different: a Kaizen.

Here’s what we did, what we learned, and how it went.

What is a Kaizen?

Kaizen is a Japanese business philosophy that can be translated to mean “Change for the better.” It can be an event, too.

Before this experiment, I’d observed a Kaizen workshop once in a factory, but I’d never led one myself, or heard of one done on a software team.

Why Run a Kaizen (on a Software Team)?

In meetings and conversations, I’d been hearing a consistent piece of feedback: our team’s knowledge base (we’re using Confluence by Atlassian) was hard to use. In knowledge work, tools that facilitate knowledge-sharing are vital.

I soon learned that a nuclear approach— “Let’s build a new knowledge base”— had been tried and failed. Kaizen approaches problems from a different direction: instead of starting over, Kaizen looks for inefficiency, or “waste,” in the current system.

I thought it was worth a try! As a guide, I used The Toyota Way by Jeffrey K. Liker.

Scheduling the Workshop

First, I scheduled the workshop with a group of people I knew cared about this issue. Four engineers. These are stakeholders who use the tool daily.

We allotted three hours. Kaizen workshops can take much longer, like a week.

Planning the Workshop

I knew the problem well, so I decided to plan alone. Lean concepts are in italics.

First, I defined the problem:

“Our Confluence space is hard to navigate, inconsistent, and underutilized.”

Next, I defined why it matters. The current solution causes:

  • Time wasted searching for information
  • Mistrust in documentation accuracy
  • Duplication of effort
  • Risk of sharing outdated or incorrect information internally or with customers (!)

Then, I defined the goal of the workshop:

Make it easier and faster for team members to find, contribute to, and trust the documentation.

Next, what success would look like:

  • Clear structure and navigation
  • Up-to-date, trustworthy content
  • Clear ownership and processes
  • Team culture that values good documentation

Next, I set objectives for the workshop:

  • Improve the discoverability of documentation
  • Archive or remove outdated content
  • Clarify document ownership and maintenance responsibilities
  • Define a simple, visible process for requesting and approving documentation changes
  • Encourage and normalize contribution—create a culture of documentation and technical writing

You can take more preparatory steps, like:

  • Audit existing Confluence spaces, pages, and contributors
  • Inventory how many spaces exist and what kind of documentation lives in each
  • Identify common pain points: what’s hard to find? What’s outdated? What’s duplicated?
  • Gather anecdotes or examples: “I found a doc that said X, but it was from 2019”

We all had these more or less in our heads already.

The Workshop

Finally, the day of the workshop arrived!

As the workshop facilitator, I gave a brief introduction to Lean, Kaizen, and workshop goals. We reviewed my preparation, objectives, and general flow of the event.

We began by identifying the customer. This little step unearthed lots of surprising conversations! We quickly learned our Confluence serves more than just engineers. Here was our list of customers:

  • Engineers, PMs, Designers
  • Sale staff
  • Management
  • Customers (!)
  • Potential customers
  • New hires
  • External partners

Next, we considered what these customers need:

  • Engineers, PM, Designers: Technical info, guides, and docs that answer questions
  • Sales staff: Learn how to interact with engineering team, processes, and searching
  • Management (CTO, CEO): Need to see how awesome we are! Understand internal processes. Learn how to interact with engineering team and execute procedures
  • Customers (via PDF or public link): Need guides and docs that answer questions, help themselves, expecting a higher level of polish
  • Potential customers: Need onboarding, setup, guides
  • New hires: Need access to institutional knowledge and onboarding

Then, we mapped the current state, known as Genchi Genbutsu (“Go and See”). We walked through the current process on a whiteboard, trying to answer:

  • How do documents get created?
  • How do team members find them?
  • How is accuracy maintained?
  • What happens when something is wrong?

Next, we labeled each step of the map as value-added (VA), required but non-value-added (NVA), and pure waste.

Finally, we developed the future state vision. We brainstormed ideas for improving each part of the process, using notes to mark ideas on the whiteboard.

Here were our action items leading to the future state:

  • Cleanup unused Confluence spaces, and schedule periodic review
  • Restrict who can create spaces to raise quality and prevent duplicative work
  • Research requiring captions and alt text so images are more searchable
  • Research adding labels to posts for better categorization, and making them required
  • Research crowdsourced feedback on pages 👍 👎
  • Research how Confluences links are shown in chat. Can we get a better preview?
  • Research how to show stale documents

Result

I feel we made massive progress in a few hours of work. Here are the results of our check-in two weeks later:

  • We cleaned up dozens of unused Confluence spaces, making the remaining ones more discoverable
  • We considered and rejected restricting who can create spaces, after learning that wasn’t a persistent concern
  • We learned that image captions are a feature in Confluence and alt-text is not
  • We learned that feedback can be added via an emojis or third-party plugins
  • We shared how to install a chat plugin to make Confluence links richer in our chat application
  • We looked at how to surface stale documents

Did we “fix Confluence”? No— but that wasn’t the goal. What we did do was identify real problems, share knowledge, and start treating documentation like a product worth iterating on.

Most importantly, we practiced continuous improvement together.

If you’ve ever tried to apply Lean concepts to software engineering, I’d love to hear about it!