So by now the PMI Agile Certification is probably old news to most folks. There have been plenty of blog posts on the topic. One of my favorites was that of Dennis Stevens, found here.
I was thinking about the bigger picture of what the certification can mean. Back when I got my PMP certification (about 10 years ago now), not a lot of people knew what it was. Now most jobs for project managers ask for the PMP certification. With PMI's large membership and reach, I think this will help agile project management become more mainstream.
As a case and point, I started a new project the other week. The project included IT folks on the client side, plus some consultants (from one of the big firms). They talked about doing the project using agile and iterative techniques. I even spent time walking them through the agile methodology my company developed. However, two days later, they were asking when I would provide the "detailed project plan." It was clear that in spite of their words, they really didn't get what agile was.
Now that PMI is doing agile, it's going to get more attention among main-stream project managers. My hope is that people will at least take a few minutes to understand some of the principles (Dennis's post laid them out nicely). Now I know agile is not the right approach for every project. However, I think in order to make an informed decision, you need some facts. And when you find yourself in an agile project, you at least know the right questions to ask.
Monday, February 28, 2011
Wednesday, February 16, 2011
Three Cups of Tea
I just finished reading the book Three Cups of Tea. I highly recommend it.
The book is a true story about an American mountaineer (Greg Mortenson) that while descending from K2, gets lost and ends up in a small village in Pakistan. The villagers take him in and help him recover from the stress of the climbing. When he sees the school children studying in the open, he vows to raise money and come back to build the village a school.
The rest of the book is about how Mortenson builds schools throughout the region.
While not a real project manager, he was successful. One of his key skills for success was his ability to communicate. Throughout the book, he is learning the local languages of the people he works with, including Balti and Urdu.
However, Mortenson's the real reason for his success was due to his ability to understand the people he was working with. Each region he worked in had different customs, languages, and problems that he took the time to understand.
I think this is the lesson project managers should know, especially in this day of global projects. Taking the time up front to get to know our team as individuals will help us down the road.
The book is a true story about an American mountaineer (Greg Mortenson) that while descending from K2, gets lost and ends up in a small village in Pakistan. The villagers take him in and help him recover from the stress of the climbing. When he sees the school children studying in the open, he vows to raise money and come back to build the village a school.
The rest of the book is about how Mortenson builds schools throughout the region.
While not a real project manager, he was successful. One of his key skills for success was his ability to communicate. Throughout the book, he is learning the local languages of the people he works with, including Balti and Urdu.
However, Mortenson's the real reason for his success was due to his ability to understand the people he was working with. Each region he worked in had different customs, languages, and problems that he took the time to understand.
I think this is the lesson project managers should know, especially in this day of global projects. Taking the time up front to get to know our team as individuals will help us down the road.
Wednesday, February 09, 2011
Domain Knowledge
So a topic came up this week that has been a subject of debate for as long as I've been a PM surfaced. How much domain knowledge does a PM need to be successful? Does a PM over a .net shop need to have programming experience in .net? Or can any PM be successful on any project?
I think the reality is somewhere in between. A technology PM wouldn't be effective at building a bridge, but a good technology PM could run most technology projects successfully. One reason is that all projects are, by definition, unique. Having a specific set of skills will help, but the PM is going to be learning on the job as well.
This highlights one of the skills I think is important for a PM, being able to learn quickly. How well can you figure out what's new and unique about your project and how quickly can you apply your experience to this new situation? The term "hit the ground running" applies here. I may not have done .net projects before, but I have done J2EE, so I have a point of reference to learn what I need to know about .net.
How can a PM get good at hitting the ground running? One key is having a thirst for knowledge. Catching up on the latest technology between projects or during slower periods. Going into every new engagement looking for learning opportunities. Not being afraid to ask questions of the experts. So what have you learned recently?
I think the reality is somewhere in between. A technology PM wouldn't be effective at building a bridge, but a good technology PM could run most technology projects successfully. One reason is that all projects are, by definition, unique. Having a specific set of skills will help, but the PM is going to be learning on the job as well.
This highlights one of the skills I think is important for a PM, being able to learn quickly. How well can you figure out what's new and unique about your project and how quickly can you apply your experience to this new situation? The term "hit the ground running" applies here. I may not have done .net projects before, but I have done J2EE, so I have a point of reference to learn what I need to know about .net.
How can a PM get good at hitting the ground running? One key is having a thirst for knowledge. Catching up on the latest technology between projects or during slower periods. Going into every new engagement looking for learning opportunities. Not being afraid to ask questions of the experts. So what have you learned recently?
Tuesday, January 25, 2011
The Zeigarnik Effect
An interesting discussion came up on one of the agile groups I subscribe to; the Zeigarnik effect. What this theory says is that people remember unfinished tasks better than they remember finished tasks.
The context of the discussion was retrospectives. During a retrospective, people will be less likely to remember the tasks that completed smoothly in the project, things that fall under the category of what did we do well. Since these are important, you want to make sure people remember them.
One of the tools I use in retrospectives come from Norman Kerth's book. The tool is building a timeline of the project and having people identify key events throughout the project. This is one way to help people remember. Another technique is to hold your retrospectives often; at the end of the iteration rather than waiting until the end of the project.
As I was thinking about the Zeigarnik effect for this post, I also realized it impacts your work in progress (WIP) limits for Kanban. The more things you have in progress, the more things that you are trying to remember. Get your WIP to high, you start forgetting what you're supposed to be working on. So how much unfinished work are you trying to deal with?
On a side note, if you teach, you can use this effect to your advantage. Give your students an assignment right at the end of the day. They will keep thinking about it until they have time to finish it. They'll learn their lesson better than if they finished the assignment in class.
The context of the discussion was retrospectives. During a retrospective, people will be less likely to remember the tasks that completed smoothly in the project, things that fall under the category of what did we do well. Since these are important, you want to make sure people remember them.
One of the tools I use in retrospectives come from Norman Kerth's book. The tool is building a timeline of the project and having people identify key events throughout the project. This is one way to help people remember. Another technique is to hold your retrospectives often; at the end of the iteration rather than waiting until the end of the project.
As I was thinking about the Zeigarnik effect for this post, I also realized it impacts your work in progress (WIP) limits for Kanban. The more things you have in progress, the more things that you are trying to remember. Get your WIP to high, you start forgetting what you're supposed to be working on. So how much unfinished work are you trying to deal with?
On a side note, if you teach, you can use this effect to your advantage. Give your students an assignment right at the end of the day. They will keep thinking about it until they have time to finish it. They'll learn their lesson better than if they finished the assignment in class.
Friday, January 21, 2011
Who do you hang out with?
It is often said you are a reflection of a few people you spend the most time around, so are you making good decisions about who you spend time with? As a triathlete, I know if I spend more time with fellow athletes, I will work out more. The other week I did a 30+ mile bike ride with some teammates. It was freezing weather (17 Fahrenheit/-8 Celsius) and we rode for over 2 hours (at which point my water bottles were frozen solid). I would never have done a crazy ride like this on my own, it was only because of the people I was with that pushed me to go so far.
The same thing can be said of our work-mates. If you're always spending time with the person complaining about how they don't like their job, you will start getting a negative attitude. If you spend a lot of time around a workaholic, you'll probably find yourself working more hours.
A lot of times we don't have much control about who we work with, but there is something you can do. Find someone that has those skills you want to improve on; maybe being better at public speaking or being more proactive. Now ask this person if they would be a mentor for you. If you spend even a couple half hour sessions a week, they will start influencing your behavior. It could be as simple as having coffee one day and lunch another day (you can usually decide who to spend lunch with).
The same thing can be said of our work-mates. If you're always spending time with the person complaining about how they don't like their job, you will start getting a negative attitude. If you spend a lot of time around a workaholic, you'll probably find yourself working more hours.
A lot of times we don't have much control about who we work with, but there is something you can do. Find someone that has those skills you want to improve on; maybe being better at public speaking or being more proactive. Now ask this person if they would be a mentor for you. If you spend even a couple half hour sessions a week, they will start influencing your behavior. It could be as simple as having coffee one day and lunch another day (you can usually decide who to spend lunch with).
Wednesday, January 19, 2011
Inspections
I have a client that has a practice of doing inspections, such as requirements inspections at the end of the analysis phase. Most of their projects follow a waterfall methodology. They implemented the practice because they were finding to many defects in testing and production, and they wanted to be able to identify defects earlier in order to reduce the cost to fix them. For their waterfall environment, that seemed like a logical approach to them.
However, we started talking about if/how inspections would work with agile, and particularly Kanban. We had just wrapped up project using Kanban techniques, and there were no defects found in testing. So if we did inspections, how would we do them?
On our project, our cycle time was 2-3 days per feature. We would then review/gain acceptance of that feature with the business owner. While this might seem like an inspection, it wasn't the same as what our client was doing. Their inspections didn't involve the business owners. A typical requirements inspection would involve the business analyst, someone from the quality engineering team, and someone from testing. So this would be an additional step every 2-3 days in our approach. As a lean advocate, my question is "what value does this add?"
The real answer goes back to Deming, and the 3rd of his 14 points (slightly paraphrased) - don't rely on inspections to ensure quality, build quality into the product from the start. If your quality assurance approach consists just of testing at the end of development, you aren't meeting Deming's point. However, if you have other QA activities such as paired programming, TDD, code reviews, frequent feedback from the business owner etc, you don't have to rely on testing to find all your defects, you've already worked them out, or at least most of them.
That's not to say we don't do any testing. It's still part of our overall QA approach. We also conduct our retrospectives to see how we can fold even better QA activities into our next project. I think with a couple more successful projects, I'll be able to get the client to see my perspective on this.
However, we started talking about if/how inspections would work with agile, and particularly Kanban. We had just wrapped up project using Kanban techniques, and there were no defects found in testing. So if we did inspections, how would we do them?
On our project, our cycle time was 2-3 days per feature. We would then review/gain acceptance of that feature with the business owner. While this might seem like an inspection, it wasn't the same as what our client was doing. Their inspections didn't involve the business owners. A typical requirements inspection would involve the business analyst, someone from the quality engineering team, and someone from testing. So this would be an additional step every 2-3 days in our approach. As a lean advocate, my question is "what value does this add?"
The real answer goes back to Deming, and the 3rd of his 14 points (slightly paraphrased) - don't rely on inspections to ensure quality, build quality into the product from the start. If your quality assurance approach consists just of testing at the end of development, you aren't meeting Deming's point. However, if you have other QA activities such as paired programming, TDD, code reviews, frequent feedback from the business owner etc, you don't have to rely on testing to find all your defects, you've already worked them out, or at least most of them.
That's not to say we don't do any testing. It's still part of our overall QA approach. We also conduct our retrospectives to see how we can fold even better QA activities into our next project. I think with a couple more successful projects, I'll be able to get the client to see my perspective on this.
Tuesday, January 11, 2011
A new habit - daily retrospectives
So I'm trying to build a new habit. I've heard it takes 30 days for a habit to take hold, so check back in a month to see how I'm doing.
So what I'm trying to do is a mini retrospective at the end of each day. I'm taking 5 minutes before I wrap up for the day to ask myself a couple questions and jot down some brief responses in my journal;
So what I'm trying to do is a mini retrospective at the end of each day. I'm taking 5 minutes before I wrap up for the day to ask myself a couple questions and jot down some brief responses in my journal;
- What were my successes and challenges?
- What did I learn?
- Who should I reach out to?
Subscribe to:
Posts (Atom)