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.