Making your problems visible

For the past 2 days, I've participated in the PMI Kansas City Chapter's Professional Development Days. On Monday, I gave an overview of Scrum. Yesterday I gave a presentation on User Stories. One thing I mentioned in both presentations; while Scrum won't fix all your problems, it will make them more visible so that you have to deal with them.

After yesterday's presentation, one attendee came up to talk about a problem he was having with his projects. His end users were very slow at providing requirements information. Questions in emails would go unanswered for a week or more. If he got key stakeholders together on a conference call, they would debate among themselves and no decisions would get made. Being geographically dispersed added to the problem.

My advice to him was to capture as much detail as he could but don't hold up the iterations waiting on input. He should build what he could based on the limited input he got and push things to production. An application with limited functionality was better than no application at all, and this would help force the stakeholders to provide additional input.

I find the same advice applies when I'm implementing business processes. If a process is broken, taking any step to quickly apply a fix is better than doing months-long analysis on what the solution might be. Once the quick fix is applied, you can see how effective it is and move forward from there.

It's application of kaizen and lean. Find the biggest issue, take care of it, then go back and see what your next biggest issue is. I told my presentation attendees that they should look at their projects with a product view; they may not get everything right in the first release, so they should plan on going back and updating the application in the future.

More on Servant Leadership

I had an article published in the PMI Community Post last Friday on Servant Leadership. You can read it here. I've had a lot of feedback on the article and wanted to expand on what I said in the article.

Is Servant Leadership the only leadership style that a project manager should follow? The answer is no. Just like any other tool, this leadership style has its place. However, this style of leadership is part of the bigger picture. To be effective as a servant leader requires honesty, openness, willingness to listen, and compassion. Skills required of a servant leader, but of a good leader in general.

A project manager will be called on to perform other tasks that don't fit into the servant-leader model. For example, there may be a conflict on the team that the project manager has to step in to resolve. There's more management specific tasks like assigning resources or managing the budget.

So the project manager has to recognize when they should put on the servant leader hat. Following an agile project management approach leaves plenty of opportunities for acting as servant. The team is self-organizing, so they decide how to complete the work. The product owner is the one that decides on the scope of the project. The role of the project manager is to see that the process is followed and that obstacles are removed.

That's not to say that a project manager has to be following agile to be a servant leader. Really, any leader can follow the servant leader model. They just need to be aware of opportunities where they can serve the team in order to further to goals and vision of the team. In the words of Lao Tzu, "The greatest leader forgets himself and tends to the needs of others."

Keeping Honest with Metrics

Last weekend I purchased the Nike + iPod device. It's a small sensor that fits into my running shoe plus an interface unit that plugs into my iPod. It keeps track of how far I've run, my pace, even calories burned. It's really pretty effective and accurate.

What the tool is really doing for me is keeping me honest. I used to go out and run for 45 minutes or an hour and not worry about the pace. "I'm going around 8:00 minute/mile pace" is what I would tell myself, knowing a lot of times I was really going slower. With my new toy, I know exactly what pace I run. The end result is I am running harder so that I do keep at 8:00 minute pace or better. The proof is here.

This same theory applies to managing business processes. Maybe you know it takes about 5 business days to do end of month processing and get your invoices out the door and your customers take around 30 days to pay the invoices. Is this good? If it used to take you 8 days to do invoices, this is an improvement, but do you really have the metrics to make good decisions? Should you work to improve this process, or is there another process that would be more important to focus on?

However, let's say you knew that by cutting your invoice processing to 4 days and getting your money into the bank sooner, you would earn another $21,000 in interest a month. Now there seems to be more value in capturing detailed metrics on your process and using those to optimize the process.

Like my running, businesses need good metrics in order to run the business effectively. In my case, the results will be in my race times, not increased profits, strong stock price, or increased customer satisfaction.

Simplify, or the problem with Six Sigma

I was on a conference call last night with the other members of the PMI Agile Community's steering committee. Last week we had a successful launch event at Agile 2009 in Chicago and we were discussing how we continue to move forward.

We were discussing vision and values and principles and finally one of the members called "in the grass" meaning our discussion was getting to detailed. As another member stated, we should be focusing on short term plans, not some long term vision when it's hard to figure out what any of us will be doing a year from now.

At this point, I recall a conversation I had with David Allen, author of Getting Things Done. He said we tend to want to focus on where we feel the pain. If our boat just hit the rocks, we don't think about our ship's vision, we figure out how to fix the hole.

To me, this is one of the challenges with Six Sigma. Taking a traditional DMAIC approach takes some time, 6 months is not uncommon for a DMAIC project. There's a lot of analysis that happens before any changes are made. I prefer a Lean approach. Go in, make a quick assessment, improve on the process, and then take another quick look at where to go next. I've implemented new business processes in as little as 3 months with only 1-2 weeks focused on analysis.

With my Agile Community it's even simpler since we don't have any processes in place yet. We need to try some stuff out and see what works. That's not to say a vision isn't important, it helps us make the right decisions. However, now that we're getting members, we need to think about what we have to offer them so they find value in our group. A year from now we can conduct our retrospective, figure out what works and what doesn't, and adjust our vision then.

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.