How are you motivating people

I just finished watching a presentation on Ted by Daniel Pink on motivation in the workplace. He sited a study that found that for anything other than simple mechanical tasks, the higher the reward, the poorer performance got.

He mentioned three things to motivate people effectively; autonomy, master, and purpose.

• Autonomy is the desire in people to have control over our own lives
• Mastery is the desire to continue to improve on a skill or set of skills
• Purpose is feeling like your part of something important, something bigger than yourself

As I listened to this, I realized he was describing the team structure in agile project management. The team is self-directed, deciding among themselves how they are going to accomplish the work as opposed to being assigned tasks from a command & control project manager. Along with this, they are self-motivated and empowered to learn and improve their skills. Finally, any good project starts with a vision, defining the purpose for their work.

When I'm giving presentations, I talk a lot about how you can improve productivity by following an agile process. I often refer to a study done by the Standish group about how many software features are never used (45%) and that by not building features that aren't used through a prioritized backlog, you increase productivity.

This study provides another reason why agile works; the agile team is motivated the right way to perform rather than provided incentives that have the opposite effect. So next time you're trying to get your team engaged, think about this. Are you going to throw money at them or provide the intrinsic motivators that will really get them to perform?

Kanban for process improvement

Kanban is a popular topic these days in the agile world, even spurring some debate about whether or not it is a lean technique. While is does move away from some of the standard elements of agile such as fixed length iterations, in my opinion this is another good tool for any project manager's toolbox. If you're looking for a good overview of Kanban for software development, go here.

As I was thinking about it, I could see how Kanban would be especially effective in Business Process Improvement (BPI) where Lean is being used. The idea to BPI is to apply Kaizen; find an improvement, implement it, watch the results, and then figure out the next improvement and repeat the cycle.

Kanban would work well because you aren't trying to build up a long queue of improvements. The completion of one improvement is the signal to examine your process and identify your next improvement; just like running low on a part in manufacturing is the signal to get more parts.

For example, you've implemented a new business process in your organization, most likely with a BPM tool. A good BPM tool will capture metrics on project execution; how long are various steps taking, are there bottlenecks, are exception paths being followed a lot etc. Based on this, you would identify the next improvement. Maybe, for example, putting in some business rules to automate an approval that is currently a manual step. This improvement would go through your development cycle and be implemented. At this point, your queue is empty; signaling for the next improvement. Or it could be you already have a list of improvements, you just need to pick the next one off the list and move it to the first queue in your development process, which may be elaboration. When it moves on to the next queue (development maybe), something else moves into the elaboration queue. With Kanban, you've turned your development lifecycle into more of a pipeline and your process keeps improving.

The need for agile

So I have a client that is primarily a waterfall shop (at least in the team I'm working with). I was actually surprised because this isn't some low-tech organization but a Silicon Valley tech company; I was expecting agile to be part of their project methodology but they pretty much follow waterfall.

When I started digging into how they run projects, I came across some interesting information. They spend a fair amount of time up front gathering requirements, so I was thinking if requirements are stable, maybe this is ok. But when I asked about changes, they indicated they do have a fair amount of changes once the business owner sees what is being developed. Add to this projects that are taking longer than they want and a lot of time testing and fixing bugs after coding is done.

If this isn't a classic need for agile! They said that they had tried agile before but it hadn't really worked. However, as I talked about some of the benefits of agile, they seemed willing to try. So now I'm working on setting up a pilot project to test an agile approach.

There are a number of reasons an agile implementation can go wrong. It needs executive support, the team needs the proper training, project managers need to accept their new role. We'll see how things go here, but I'm optimistic. Having been in consulting for some time, I can usually sense if my recommendations are going to be implemented or if things will go back to status quo after I leave.

If a tree falls in the woods...

I came across the Copenhagen Interpretation in a book I'm reading. This idea came about in quantum mechanics by Niels Bohr, Werner Heisenberg and others, working in Copenhagen in the early 20th century. In simple terms, the Copenhagen Interpretation says that something doesn't exist until we observe it. So if a tree falls in the woods and no one is there to hear it, it doesn't make a sound.

So what are we trying to observe on our projects? What do we try to capture by our reports, metrics, SLAs etc? The Copenhagen Interpretation supports the idea that we get what we are looking for.

I was doing work at a call center one time. There, they were looking at what percent of time the representatives were available to take calls and when they were "logged out" meaning they were taking a break, doing documentation from a previous call etc. This data point was pretty consistent across the representatives. However, when they dug a little deeper, they found a small set of people that answered significantly fewer calls. This didn't make sense since their availability was the same as others.

As it turns out, some representatives figured out how to scam the system. They watched the representatives around them getting calls and could predict when they would get a call. They logged out for a few seconds, the call went to the next representative over, and they logged back as available, knowing they wouldn't get another call sent to them for a while.

So you're going to get the behavior you look for and reward. If you reward the number of bugs the coders find, they'll find a lot of bugs. If you recognize the person that can fix the crisis, you'll get a lot of fires that need to be fought. So don't think lightly about what you measure.

Anti-Patterns in Project Management

I'm on a project now working with a client on best practices for BPM projects. My focus is on the project management aspect and I have a couple co-workers focused on the software development aspects. One of the topics that came up this week was anti-patterns.

Anti-patterns can be thought of as repeating a set of actions that are anything but a best practice, or, just repeating a bad habit. It's a pretty common theme in software development. Spaghetti code is a good example, continuing to produce code that is poorly structured, confusing, or hard to follow.

But as I was thinking about it, I realized anti-patterns can apply to project management as well. I was in one organization that practiced the "death march" anti-pattern. Projects would get going, everyone would know it was going to be a disaster except senior management, and then the meltdown would happen. Then everyone gets assigned to the next project.

Another of my favorites is management by fire fighting. It's only the fires that get attention and the fire fighter working the long hours saving the day is recognized as the hero. If the organization was a little better at addressing risk, it might have a few less fires (not to mention stop rewarding people for putting the fires out if they could have prevented them in the first place).

So what anti-patterns are in your organization? Can you do something to replace them with some best practices? Are you so caught up in the day to day execution of your projects that you don't see them?

The Five S's of Lean

One of the principles of Lean is known as the 5 S's. Developed in Japan, they are 5 steps that are taken to help become a more lean organization, all starting with the letter S. In English, they have been translated as Sorting, Setting in Order, Shining, Standardizing, and Sustaining. Though the concepts focus on manufacturing, they can also be applied to knowledge workers.

Sorting - What does your desk look like? Do you have piles of papers or magazines you hope to get to some day? Lots of extra cables hanging around? Business cards waiting to be put into your contact management system. The first step in becoming a lean knowledge worker is to sort your desk and office area. Keep only what you are going to need on a regular basis close by.

Setting in Order - Similar to sorting, but with more of a focus on your process flow. It's answering the question of where is the best way to arrange what I need on my desk? When I sort, my computer is something that is on my desk; when I set in order, I set up my laptop just to the left of center, with a second monitor in the center of my desk. I have a space to the right of my mousepad for documents I am working on. Setting in order becomes more important when I'm working on a client site. I have to set up every morning and need to adjust based on how much space I have. If I'm in a conference room with other people, my space may be very limited.

Shining - At the end of each day, taking a few moments to make sure your workspace is clean. Throw away that candy wrapper that's behind your monitor, sort any papers you are done with, and put books back on the shelf.

Standardize - It's important to set up standards with the people you are working with. Do you have an in-box you want anyone from your team to put papers into? Do you have a standard time for your daily stand-up meeting?
Sustain - Keeping the practice going and revisiting the other four S's when you need to. If you get a new, larger monitor, you will have to sort and straighten. If a new member joins the team, how does that change your standards within the group. Sustain is kind of like kaizen, you don't go through an improvement and stop; you keep looking for improvements.

How much technology do you need?

In an interesting twist, today's stage of the Tour de France was run without race radios (article). Normally the radios are used for the team directory to communicate to the riders; things like when the next climb is, potential hazards, or where a rival is in the race. It can become important if a small group of riders break away ahead of the pack; knowing if any of those riders can take over the lead of the race and therefore need to be chased down. So it provides additional information to the riders to help decide on tactics.

The question is how do the radios impact the race? Riders seem to prefer the radios, knowing exactly what's going on. The organizers that put the radio ban in place for today thought it might add some drama. Looking at today's results, I don't think it had a big impact either way.

This got me thinking about tools to help run projects. In the workshop I ran this past weekend, I took a very manual approach; using note cards etc. I mentioned some of the tools that are available, but also said I prefer the manual approach whenever possible. If you have a team co-located, you can get away with posting your user stories as note cards on the wall and writing your burn-down chart on a white board. Things get more complicated when teams are spread across multiple locations. That's when you need to start looking into tools.

So if you're spending a lot of time keeping your tools up to date, you have to think about what value it brings. If the answer is not much, then maybe you should try going without, like the riders did today in France.