For the first half of my career, I found the term transparency to be kind of, well … scary. Not because transparency itself is bad, as much as it’s step-children and cousin words — governance and accountability.
Governance, to me, meant that someone up above didn’t know what was going on, so they were going to give us still more work to prove something. Exactly what we were proving was always sort of undefined; it felt a bit like a tiger chasing its tail.
Accountability wasn’t much better; it meant that someone would call us to “account” for missing the commitments someone else made six months ago to project deadlines, before they really knew what the project was going to be. Even if the estimates were good, because the steering committee was probably going to add more work without shifting the deadline, then call us to “account” for “missing” the deadline.
I’m not really this cynical. I just want to set explain what my reaction would have been to a word like transparency ten years ago.
Today, I think transparency is the secret sauce. It is the magic milk, the healing homebrew. All those problems above go away with transparency implemented correctly.
Let me give you an example.
Transparency in Action
Say I have far too much work to do, and not enough time to do it — but I can break the work down into tasks that can be done in an hour or so. Not all kinds of work falls into this category, but a lot of what I do, testing, configuration, consulting — a lot of it does.
I make three columns on a white board – “To Do”, “In Process”, and “Done”, then write down a sticky for each task. Once the setup is done, I pull the first task from “To Do” to “In Process”, and work on one thing at a time. Now this isn’t a perfect list; there is no tasks for “check email” or for scheduled meetings, but for the most part, my tasks are modeled on the board.
Any leader, any boss, any executive that walks by can re-arrange the tasks, and put something to the top. Because the tasks are small, I can tell you how long it will take on average from putting a task to the top to moving it to done. If I want to, I can count the number of tasks I get done per day, to predict when things will get done. A process improvement wonk would call this a “kanban” system, and they’d be right – but a Kanban is simply a Japanese word for tag system to manage a flow of work.
Here’s a Kanban that I set up at a client a few months ago; the tasks are a list of business risks we were testing for:
We had five team members on the project, thus, give items or less of work in progress on any given time — when we were pairing, we’d have less. If we were under pressure and had to ship, management could look at our ideas to test remaining (and we always have more ideas) and decide the benefits outweighed the risk.
Think about how that decision changes things when there are problems in production, versus the ancient model of testers “certifying” software for release while under time pressure.
Kanban and You
Imagine walking into an annual review meeting and finding out you worked on the wrong thing, or your priorities were wrong, or, after 12 months, your manager was disappointed you hadn’t accomplished (some_thing).
Only this time, you had a kanban. Everything you did was visible. Anyone in leadership could see them, adjust them, ask “What about (some_thing)”, create new stickies.
At that point, the person who has the problem is the reviewer, right?
I don’t mean to be manipulative here — the point was just to illustrate how powerful this kind of transparency can be. What I have above is just one way to model a Kanban (it is a team board) and Kanban is just one way to make the work visible. For more, check out Jim Bensen’s book “Personal Kanban”, or keep it tuned here.
Until then: Have you tried some form of radical transparency? When you did, what kind of results did you have?