How to create a knowledge worker Gemba

I am a big fan of the work by Jim Benson and Tonianne Barry ever since I read their book: Personal Kanban.

In this article Jim describes an idea that I would like to highlight and expand. He says: we need a knowledge worker Gemba. He goes on to describe how to create that Gemba:

• Create a workcell for knowledge work: Where you can actually observe the team work and interact
• Make work explicit: Without being able to visualize the work in progress, you will not be able to understand the impact of certain dynamics between the team members. Also, you will miss the necessary information that will allow you to understand the obstacles to flow in the team - what prevents value from being delivered.

These are just some steps you can take right now to understand deeply how work gets done in your team, your organization or by yourself if you are an independent knowledge worker. This understanding, in turn will help you define concrete changes to the way work gets done in a way that can be measured and understood.

I've tried the same idea for my own work and described it here. How about you? What have you tried to implement to create visibility and understanding in your work?

Which do we need the most, Project Managers or Line Managers?

Should we organize around the delivery of products or along the structure of our organization? Which organizational paradigm is the most effective or efficient?

This is a question that most managers struggle with regularly. At least when they are asked to "re-organize" their respective organizations.

In Europe (and I suspect elsewhere) this has led to a huge growth in what I would call Hybrid organizations. Also known as "Matrix organizations". These are organizations where managers try to blend delivery-focused (project) organizations with hierarchical-focused organizations (the line organization).

Which organization is better?

Just this week I had an argument with a colleague about this. Which of this organizational paradigms is better? It is my view that both of these options, actually all three (if you count the matrix organization) represent a fundamental lack of understanding of how knowledge work happens and how it gets done.

The Hierarchy-focused organization is based on the principles that we need to have someone to "manage" the worker. As if the worker herself would not be able to make decisions about allocation of resources or conflict resolution without the contribution of a higher manager.

The Project-focused organization is based on a similar principle, the principle that the worker cannot make execution-relevant decisions herself. For example, which piece of work to do first, or where to get some necessary information.

The Matrix organization may be based on both of these ideas, i.e., that the worker cannot do any type of decisions herself...

I believe these principles (and the associated practices) are wrong. I believe that we can have organizations that are focused on delivering concrete products / services to the customers without having to have any of these layers to "manage the work and the worker".

Why should we have Project Managers and other interesting arguments...

My colleague was arguing that we don't need Project Managers in an organization because they don't deliver anything. "They are overhead that produces no value outside coordination" he said. Sure, I can buy that, but what do line managers do that cannot be classified in the same way? The answer is nothing. Line manager's work is mostly overhead as well. They don't - on their own - deliver anything to the end customer, and do mostly coordination work (for example: coordination of performance reviews).

So the question is: If we believe that Project Managers "add no value" to a knowledge organization, why do we have line managers?

What do you think would be my colleagues answer to that question?

Photo credit: miuenski @ flickr

Can Scrum and Kanban be used for non-software development work?

Can Scrum or Kanban be used to manage any other work than software development? Do the same concepts apply?

The past week-end there's been some chatter on twitter about using Kanban or Scrum for managing work outside the software development realm.

People seem (pleasently) surprised that it can be done. But can it really? The answer is YES! But why do methods that were clearly developed with software development in mind expand to manage other type of work?

Well, we have to look at the roots of these methods to understand that. Both Kanban and Scrum based their core practices around a list of "stuff" to do. Features/stories in software development fills these lists or backlogs, but in an advertising agency, for example, the "stuff" will be something like drawing proposals for clients, brainstorming meetings, research work, etc.

Through these lists, Kanban and Scrum establish an order of work (what to do now?) and allow what is normally a disconnected mass of work to be organized in a way that a team can use, not only to execute, but also to follow-up their work (e.g. through a burndown/burnup chart)

Indeed, at the root both Kanban and Scrum are just formalized work management methods that were created to overcome the chaos that is still so normal in software development organizations. The hidden truth however, is that the same chaos is present elsewhere and those companies can benefit as much from Scrum/Kanban as the software industry is benefiting now.

The corollary of this is that Scrum/Kanban can be used to do anything, from building a space ship to planting potatoes, and I have even used it for personal non-software development work as well as helped others establish some of the ideas behind Scrum as their own "working method".

There's a catch, though!

Getting back to the backlogs, both these methodologies need a steady stream of work to be analyzed, prioritized and ultimately picked up to be worked on. Because the constraint (i.e. the part in the system that is always busy) in the process is normally the project team, it is imperative that special attention be given to the backlog, where work is listed and described. It is often a good practice to regularly spend time analyzing the work in the backlog to make sure that it fits the Vision for the product/project and that it is sufficiently well defined so that the team will not lose their time trying to figure out what the work-item really means.

For this we normally have a manager (called product owner in Scrum) whose time is spent analyzing the project/product and deciphering the customer needs into a format that the team can understand.

This work is crucial, and the real reason why teams need "managers" (product owner in Scrum).

Manage your work for better performance

The key message here is this: Your work performance will only be as good as you are at managing the backlogs.

Because Scrum/Kanban are work management methods, it follows that the team's performance will depend heavily on how the backlogs are managed by the team and their manager. Therefore, the hidden pearl in Scrum and Kanban is that you should focus a lot (but not all) of energy in defining and improving how your manage your work. And this is valid for any type of work. Be it software or creative projects in an advertising agency.

Meetings are money (lost...)

Time is something that we cannot produce more of. If that's so why do we still spend so much time on meetings that are not valuable? Would you give me money if I came to you in the middle of the day or better yet, if I sent you a money request through Outlook and all you had to do was press "Accept"?

So why do you accept meetings all the time?

Great presentation by Merlin Mann on preserving your time.

Estimation is needed but useless. Do it and throw away the numbers!

I've discussed this idea a few times with some friends, but I'll concede that the ultimate argument for stopping to estimate altogether is still to come...

In the meanwhile here is more food for thought. Rob Bowley argues why estimations are bad in software development.

My favorite part of his presentation:
[In a study discussed in Peopleware by Lister and De Marco, it was found that "the highest [software development] average productivity was on those projects that didn’t estimate at all."

Personal Scrum or Work 2.0

So, I've been inflicting Scrum on myself.

This is my "eat your own dog food" because I'm an Agile Coach at the company where I work, which in practice means that I try to work with teams and help them with Agile adoption, and in some cases with the Agile development.

For me to preach Scrum and not do it would be at least incoherent, but I can think of even less nice ways to put it.

So, back to the story. I'm using Scrum patterns for managing my own work. Let me explain this a little bit. I'm following a method for the management of my personal work that resembles and is largely based on the patterns that we see in Scrum.

Here's the key points of how it works:

1. I have the weekly planning (yes, I'm using weekly iterations/sprints) every week on Monday morning. This is where I look at my backlog (personal and team) and the list of meetings for the week and I plan what I will be doing that week. The weekly plan I put on the wall with post-its.
2. Every day in the morning (before opening Outlook) I read my task board on the wall and list for myself what I wil try to accomplish during that day (only that day). This becomes my "daily plan" for the work to be done. And the fact that I review the plan daily also helps me to
3. On Friday I finalize my sprint, do the personal retrospective and review if there's something from that retrospective that I want to add to my Backlog.

There are more details to this, but these are the key points. I'll write about the details later.
The Scrum patterns applied with the above items are:

• The planning day (point 1 above), which in my case is a planning hour (it takes between 45 min and 1,5 hours)
• The daily check (point 2), which is my review of the task board in the morning and the resulting "daily plan"
• The retrospective (point 3). Where I analyze my work week and collect "TRY" items (as in Cockburn's retrospective agenda) that I will implement during next week.

This way I stay familiar with the mechanics of Scrum (not all, but the key points) and have a method for managing my own personal work.

The results have been good. I've developed the concept of personal capacity (velocity in XP), which tells me what I can commit to and gives me a good way to communicate with my stakeholders about what I can and cannot accomplish in one week of work.

As a result of knowing my capacity I can now be proactive and manage the "pipe" of work for the next few weeks (I'm keeping a backlog of three weeks for short term actions in a limited queue: credit for Mary Poppendieck for bringing that up in the training at our company).

Maintaining the limited queue for the next 3 weeks in turn helps me not just avoid over committing to work during the ongoing week, but hopefully also for the next three weeks.

The biggest value I get out of the system though, is that now I really am in control of my work and can make informed decisions constantly. I have a proper time management system in place!

This method I call Personal Scrum, when used to manage my personal work, or Management (as in Work Management) Scrum, when used to manage the work of a management team.