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.
Wednesday, September 23, 2009
Tuesday, September 15, 2009
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."
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."
Friday, September 04, 2009
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.
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.
Tuesday, September 01, 2009
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.
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.
Subscribe to:
Posts (Atom)