Seeing the IT and Kanban Software Development Gemba

This article explains Kanban Software Development Gemba and why you should care. It’s a guest post from Jason Yip.

I’m pleased to present this guest post from Jason Yip, a respected thought-leader on Agile and Lean Software Development. Jason Yip is a Principal Consultant for ThoughtWorks, a global IT consulting firm. You may learn more about him through his blog and by following him on twitter @jchyip. In this post, Jason Yip will discuss the concept of the “Gemba” and what it means in the context of software development. For example, he will consider the following question: How does one exactly “see” to “go the actual place” when software development is in large part virtual? Read to learn how.

One of the strongest messages in Lean is to go and see. Get out from behind your desk, go to the gemba, and look.

But what I deal with are software development and IT support organisations. This is knowledge-based work. The work items are all virtual. What does it mean to see in this context?

Let’s imagine that I drew a circle in the middle of the office and stood there until I could identify opportunities for improvement. What might I see?

I might notice that the cubicle walls prevent everyone from seeing each other. I might notice that no one ever leaves their seat unless getting a drink, taking a washroom break, or heading out to lunch. I might notice that everyone is wearing headphones. I might notice that at no point in the day does the team ever physically get together. I might notice that other stakeholders rarely visit the team nor does the team visit them. Every so often I might notice some senior stakeholder drop by, disrupt the team with some request, and leave.

The last thing I might notice is what I can’t see… Who’s working on what? What is the most important thing to do at the moment? What are the current problems? Is the current system build working? How is the overall project / operation doing?

How sure are we that everyone in the team, never mind other stakeholders, know the answers to those questions?

Let’s imagine that I now close my eyes and listen. What might I hear?

Silence… no, not quite… people hitting keys on their keyboards… someone starts playing music to fill the silence… but no talking… no, not quite… Every so often I might hear the team leader direct a team member to work on this or that…. and there’s scattered conversation… but never about the work, never about coordinating, never asking for, or offering to, help.

Now I need to leave the circle because in our world, at the end of the day there are things you can’t see unless you’re at a computer…

So I sit with each of the team members and observe… he’s unfamiliar with the editor shortcuts even though another person on the team knows them better than I do, she’s making assumptions rather than validating with the subject matter expert, he’s repeating the same task that could easily be automated with a simple script, everyone seems to do the same task in a completely different way.

I look at other things . . . alert logs: It seems that most alerts are ignored and resolve themselves without intervention… ticketing systems: A significant number of tickets are over 1 year old… the source code: Significant amount of duplication, unclear naming, no tests
And that might be it for the first day or two.

What does it already tell us about opportunities for improvement?

The IT and software development context is different from physical manufacturing in many aspects. But there is still something definitely in common . . . get out from behind your desk, go to the gemba, and look.