I found a quote today that I liked. It was on Mike Griffith's blog post on the top 10 estimating techniques. The quote was:
"If you cannot summarize it on only one page, you need to go off and learn more about it!"
This is really pretty good. I've always felt one of my strengths was the ability to summarize things effectively, but as I think about it I realize it's because I spend the time studying the subject. So next time you have to give a brief synopsis, go do your homework.
Thursday, February 28, 2008
Wednesday, February 27, 2008
Checklists
The current issue of Fast Company had an interesting article on checklist, see it here. Their argument was that checklists aren't just for the kid at the fast food place making burgers, but can help in all types of situations.
Checklists are often sited as a quality assurance tools, but how many of us really use them? When I'm preparing a customer deliverable (typically a Word document), I have a simple checklist so that I don't forget anything in the last minute rush. The checklist includes conducting a review for grammar, having someone else review the document, incorporating their feedback, checking all diagrams, running spell-check one last time, making sure page layouts/fonts etc are correct and finally checking the document properties.
This might sound pretty simple, but when things get rushed at the end of the project, my checklist keeps me from forgetting anything.
Checklists are often sited as a quality assurance tools, but how many of us really use them? When I'm preparing a customer deliverable (typically a Word document), I have a simple checklist so that I don't forget anything in the last minute rush. The checklist includes conducting a review for grammar, having someone else review the document, incorporating their feedback, checking all diagrams, running spell-check one last time, making sure page layouts/fonts etc are correct and finally checking the document properties.
This might sound pretty simple, but when things get rushed at the end of the project, my checklist keeps me from forgetting anything.
Wednesday, February 20, 2008
"Software"
I'm reading the book Implementing Lean Software Development by Mary & Tom Poppendieck and came across an interesting comment. They talk about how software by it's very nature should be easy to change, or else it would be called hardware. Good software is designed this way so that it can easily change to the changing business environment.
I know I've seen plenty of software that wasn't designed this way. It's a vicious cycle; customers ask for everything because they don't know what they really want and they know how hard it is to change once the requirements are agreed to. They get the final product and then begin to understand what they really need, but the cycle time is long, so they ask for all kinds of stuff again and it takes a long time to deliver again and their needs have changed again...
By delivering just the minimum functionality in a short cycle, the feedback loop is reduced and the customer more quickly understands and gets what they need.
I know I've seen plenty of software that wasn't designed this way. It's a vicious cycle; customers ask for everything because they don't know what they really want and they know how hard it is to change once the requirements are agreed to. They get the final product and then begin to understand what they really need, but the cycle time is long, so they ask for all kinds of stuff again and it takes a long time to deliver again and their needs have changed again...
By delivering just the minimum functionality in a short cycle, the feedback loop is reduced and the customer more quickly understands and gets what they need.
Monday, February 18, 2008
Motorcycle Maintenance
I pulled out the book Zen and the Art of Motorcycle Maintenance by Robert Pirsig. I had originally read it back in college and was curious to see how I related to the book at this stage in my life.
The book discusses the meaning of quality. As project managers, we can pull out our PMBOK and see what it says about quality from a project management perspective, but is that it?
One point he brings up early has to do with "what has gone wrong in the 20th century." He goes on to say that when we hurry something along, we no longer care about it and just want to get on to the next thing.
How often do we rush through something like our weekly status report or some test case we're working on? We're thinking about the future instead of being in the moment, as Zen philosophy would advise us. So next time you're trying to rush through things, stop, take a deep breath, and concentrate on the moment at hand. The future is just an illusion; the past just electrical impulses in our brain. It's only the present moment that counts.
On a side note, the book was reportedly rejected by 121 publishers before finally being published. That's a lesson in persistence! It's now described as the most widely read philosophy book.
The book discusses the meaning of quality. As project managers, we can pull out our PMBOK and see what it says about quality from a project management perspective, but is that it?
One point he brings up early has to do with "what has gone wrong in the 20th century." He goes on to say that when we hurry something along, we no longer care about it and just want to get on to the next thing.
How often do we rush through something like our weekly status report or some test case we're working on? We're thinking about the future instead of being in the moment, as Zen philosophy would advise us. So next time you're trying to rush through things, stop, take a deep breath, and concentrate on the moment at hand. The future is just an illusion; the past just electrical impulses in our brain. It's only the present moment that counts.
On a side note, the book was reportedly rejected by 121 publishers before finally being published. That's a lesson in persistence! It's now described as the most widely read philosophy book.
Wednesday, February 13, 2008
Running and Scrum Planning
I was trying to come up with something to blog about and was drawing a blank. It was the end of the day and I had been doing a lot of writing for a project I'm working on, so I decided to head out for a run and hope for inspiration, and it worked.
As I was out there, it occurred to me how my planning for running is similar to the 5 levels of planning for Scrum.
Starting at the lowest level, at the start of the day I look at my schedule, family activities, the weather, and my goals for the week to decide what to do for a workout that day. This is like the daily standup meeting; what happened yesterday (did I have a hard workout I need to recover from), what's planned for today (long run, biking etc), and what obstacles are there (busy schedule, bad weather).
Moving up to the next level, my weekly planning is like the iteration or scrum planning. I set some goals for the week such as the types of workouts I want to do that week, rest days, and total amount of time I want to work out (I go by time rather than number of miles). The iteration planning is looking at the features for that iteration and planning some detail to them, while still leaving some flexibility to their execution.
At the third level is the release planning; how many iterations are going to be included in the release, dates, themes, and feature sets. I break up my year into phases, starting with prep phase, going through a base phase, build phase, and then the race phase. Each phase has a theme and dates to go with it. For example, the theme of the base phase is endurance.
The next level up is the product roadmap; what is the overall theme, the big picture for the year. This year for example, my overall focus is on running a fast (at least by my definition) marathon. All the more detailed planning works around that.
Finally we get to the vision. My vision is to continue to be a competitive athlete; in running, triathlons etc. The product vision is how the product will look in the future.
So there it is. If this planning model can be applied to my running, it can probably be applied to a lot of projects, even if they aren't following Scrum.
As I was out there, it occurred to me how my planning for running is similar to the 5 levels of planning for Scrum.
Starting at the lowest level, at the start of the day I look at my schedule, family activities, the weather, and my goals for the week to decide what to do for a workout that day. This is like the daily standup meeting; what happened yesterday (did I have a hard workout I need to recover from), what's planned for today (long run, biking etc), and what obstacles are there (busy schedule, bad weather).
Moving up to the next level, my weekly planning is like the iteration or scrum planning. I set some goals for the week such as the types of workouts I want to do that week, rest days, and total amount of time I want to work out (I go by time rather than number of miles). The iteration planning is looking at the features for that iteration and planning some detail to them, while still leaving some flexibility to their execution.
At the third level is the release planning; how many iterations are going to be included in the release, dates, themes, and feature sets. I break up my year into phases, starting with prep phase, going through a base phase, build phase, and then the race phase. Each phase has a theme and dates to go with it. For example, the theme of the base phase is endurance.
The next level up is the product roadmap; what is the overall theme, the big picture for the year. This year for example, my overall focus is on running a fast (at least by my definition) marathon. All the more detailed planning works around that.
Finally we get to the vision. My vision is to continue to be a competitive athlete; in running, triathlons etc. The product vision is how the product will look in the future.
So there it is. If this planning model can be applied to my running, it can probably be applied to a lot of projects, even if they aren't following Scrum.
Monday, February 11, 2008
Continued Education
I'm back from my trip to Colorado. I wish I could have stayed longer, I don't get to see any mountains here in Kansas.
I was out there for training to earn my latest certification - Certified Scrum Master! If you don't know, Scrum is one of the popular versions of Agile project management/software development.
Even though I already knew what Scrum was about, the class was still good. Our instructor, Hubert Smits, had a lot of experience to share.
I think it's important to never stop learning. If you haven't been to a class or conference in a while, find one and convince your boss you need to go. It's the best way to get a handle on new approaches or techniques and networking with other folks will give you new ideas to bring to your organization.
I was out there for training to earn my latest certification - Certified Scrum Master! If you don't know, Scrum is one of the popular versions of Agile project management/software development.
Even though I already knew what Scrum was about, the class was still good. Our instructor, Hubert Smits, had a lot of experience to share.
I think it's important to never stop learning. If you haven't been to a class or conference in a while, find one and convince your boss you need to go. It's the best way to get a handle on new approaches or techniques and networking with other folks will give you new ideas to bring to your organization.
Tuesday, February 05, 2008
Journeys and Maps
A journey of a thousand miles starts with the first step - Tao Te Ching, Chapter 64
I've often seen the analogy of comparing a project plan to a map, where the project is the journey. As I prepare for a journey, I was thinking about this.
I am driving to Colorado today. I'll plug my destination into my car's navigation system, and it will tell me which way to drive, how far I have to go, and when I'll have to stop for gas. Just like with a project management plan, this is a good start.
However, I don't know what will happen along the way. I may hit some bad weather. I'm always in awe when I first see the Rockies. I'll have my camera along so I can capture the sights as I go, and when I get there.
Our project plan should prepare us for what lies ahead, but it can never account for every possibility, we will have to make adjustments along the way. But I also believe that the journey is half the fun, whether it's solving a challenging design issue or setting up a new development environment, I try to enjoy the things that happen along the way. Obviously, with a project, the goal is to complete on time, within budget, and with the planned scope, but we shouldn't be so focused on the end that we miss out during the journey.
I've often seen the analogy of comparing a project plan to a map, where the project is the journey. As I prepare for a journey, I was thinking about this.
I am driving to Colorado today. I'll plug my destination into my car's navigation system, and it will tell me which way to drive, how far I have to go, and when I'll have to stop for gas. Just like with a project management plan, this is a good start.
However, I don't know what will happen along the way. I may hit some bad weather. I'm always in awe when I first see the Rockies. I'll have my camera along so I can capture the sights as I go, and when I get there.
Our project plan should prepare us for what lies ahead, but it can never account for every possibility, we will have to make adjustments along the way. But I also believe that the journey is half the fun, whether it's solving a challenging design issue or setting up a new development environment, I try to enjoy the things that happen along the way. Obviously, with a project, the goal is to complete on time, within budget, and with the planned scope, but we shouldn't be so focused on the end that we miss out during the journey.
Subscribe to:
Posts (Atom)