Zen, Project Management, and Life

Afraid of Falling

2012-01-13T07:24:00.000-06:00

I was out climbing with my son earlier this week. He's home from college on break; he got serious about climbing last year and dragged me into it. My first route was pretty technical (for me) and there were a couple points when I was about to stop but I pushed through and made it to the top. When I got down, my son had some wise advice. He said I will improve if I don't worry about falling and If I'm not falling, I'm not pushing myself hard enough.

I came across a set of videos on Yahoo; The Failure Club. This was created as a reality TV show that never got picked up by a network, but it's along the same lines as my climbing; go do something without fear of failure…even expect failure…and see what happens.

It's easy to play it safe at work. We don't want to stand out as a trouble maker or risk taker, especially during an economic slowdown. But is that the best choice? If we knew our boss wouldn't penalize us if we failed, how much risk would we take? What could we achieve?

If you're like a lot of people, you came up with some resolutions at New Years. How many risky items are on your list? How many new things are you going to try? How many things that you could fail at? When I'm climbing and not having a good day, it usually isn't because I'm falling; it's usually because I'm afraid to try and I convince myself that I can't do it. So get rid of the self-doubt and don't be afraid.

Caucuses

2012-01-03T20:50:00.001-06:00

I am working in Iowa this week. Today, Iowa is the center of the universe…or at least the US. For those that don't follow American politics, the Iowa Caucus is the first stage in selecting the candidate that will run against President Obama in November. Winning here is a good first step on a long journey.

How is your project political campaign going? Are you on course to win the election? While a political campaign is a type of project, most project managers have to handle politics as a part of getting the project delivered. A good project manager knows to pay attention to their stakeholders and figure out how to resolve conflicts between parties. They can respond effectively to a negative campaign and win the popular vote.

Ignoring politics can be a mistake. A project can easily be derailed by someone that has the right influence with the right person. This doesn't mean you have to stoop to the level of a mudslinger, but you should at least be aware of the impact they can have on your project.

So after today, Iowa will fade as the political campaign moves on. Good luck in the elections.

Scaling Agility

2011-12-21T07:16:00.001-06:00

I recently had a couple articles (here & here) published in Projects at Work based on some discussions I had at the Project Flow 2011 conference. I'll admit going into this conference I wasn't an expert on Critical Chain. In one of my articles, I compared Critical Chain to Agile and came to the conclusion that Critical Chain is not a form of Agile. However, that doesn't mean they can't co-exist.

For those unfamiliar with it, Critical Chain is the project management approach based on Theory of Constraints (TOC), all based on books by the late Eliyahu M. Goldratt. Goldratt's books are interesting because they are written as novels, not text books.

The PMI Agile Community of Practice had a tweetchat last week on scaling agility with Mike Cottmeyer. One of Mike's comments was about Theory of Constraint. Mike tweeted that at the lowest level in an agile organization are small projects using Scrum. At the higher level, TOC or Kanban can come into play as the work should take on more of a flow. Mike recommended reducing the dependencies between projects and reducing bottlenecks (full Tweetchat text can be found here for PMI Agile CoP members).

So what does this mean to you? One lesson to take from all of this is that we need to constantly keep our skills up to date. Earning your CSM is good, but not enough. You need to pick up on other techniques as well, so find a conference, pick up a book or two, or get involved with the PMI Agile Community of Practice. This way you can scale up your personal skills in agile.

You Can't Learn Jazz from Wikipedia

2011-11-29T20:15:00.001-06:00

I've been listening to a series on Jazz from iTunes University. It's been interesting because they talk about a topic and then play some examples of what they're talking about. It makes it easier to understand the difference between Hard Bop and Modal when you are listening to the styles as they're discussed. Even then, I don't think you really learn Jazz until you pick up an instrument and start playing.

This got me thinking about how people learn. I often go to Wikipedia to look up some fact. This is often the case when I'm researching an article that I'm writing. As helpful as Wikipedia is, it's not a place where someone can learn a skill.

I'm starting an engagement in which I'm playing the role of mentor. I'll provide the client some basic knowledge about running agile projects, the kind of stuff you might find in Wikipedia or a good book on the topic. But then I'll observe and provide coaching. I'll share experiences from my past that are relevant. At this point it is a true learning experience.

Passing a certification exam doesn't mean we have the experience to perform a job, it means we have the knowledge. It is by applying the knowledge that we gain the experience. Sometimes we have the ability to try a new technique in the office and see how it works, sometimes a new skill is forced upon us, and sometimes we need to seek help from a coach or mentor.

As this year draws to an end, think about the skills you've developed and the experiences you've had. Has it been enough? Are starting to think about what skills you want to build next year?

A Habit a Month

2011-11-14T07:09:00.001-06:00

There have been studies that have shown it takes about 25 days of repitition to learn a new habit. So whether its trying to exercise on a regular basis or take time every day to keep up on advances in your field, it will take about a month to turn it into a regular habit.

So here's a thought. At the start of each month, identify a habit you want to build up. Work on it every day for the month. Next month, start on something else new. Or it doesn't even have to be new; it could be something you used to be better at that has become less of a habit recently.

So keep it simple. Make this new habit the first thing you do every day, before checking email or your Twitter feed. It doesn't have to be a lot of time, keep it as short as practical. Prepare the night before, whether its laying out your workout clothes or finding the article you want to read. Just keep doing it for the whole month. When next month comes around, pick something new to work on.

Less WIP for better flying

2011-11-05T16:48:00.000-05:00

I spent the end of the this week at ProjectFlow2011, a conference put on by Realization. Realization focuses on software and professional services using a Critical Chain approach.

The conference speakers were primarily Realization customers sharing success stories. One story that I found interesting was from Delta Airlines, primarily because I fly on Delta so much. The challenge Delta had after the merger with Northwest was how many different types of airplanes they had to support. There was almost no overlap between the planes Delta flew and the ones Northwest flew. Over the course of a year, Delta was able to reduce their cancellations by 62%.

One primary change had to do with reducing multi-tasking. Before the change, they would look at all upcoming scheduled maintenance on all airplanes every night and would perform any work that was on the schedule for the next 2 1/2 days. This meant each plane had some other maintenance due 2 1/2 days later. The change they made was working on fewer aircraft each night, but looking forward 15 days on each plane they worked on. By focusing on fewer planes at a time (less work in progress), they were able to keep all the planes running better.

There were a number of other companies that shared the similar stories and reduction of work in progress was one of the key tools used to improve project execution. I'll save some of the other techniques, such as buffers, for future blog posts.

Borrowers & Followers; PMI 2011 North America Congress

2011-10-25T22:36:00.000-05:00

Today was the last day of the PMI Global Congress in Dallas Texas. I've heard there were somewhere around 3000 attendees. In general, the event was similar to past years with some featured speakers, a lot of paper presentations, and the exhibition hall with vendors.

Malcolm Gladwell with PMI CEO Mark Langley

The highlight for me was the keynote speaker, Malcolm Gladwell. He talked about company cultures and innovation. The companies that are really successful aren't necessarily the ones that invent the new ideas, they're the borrowers and followers. He used Apple as an example. They didn't invent the graphic user interface or the MP3 player but they were the ones that saw the true potential of these items and brought the products to market that people wanted. Facebook was another example, it wasn't the first social media site, but the creators learned from what others had tried to come up with the best product.

There were about 55 Area of Focus presentations. I primarily attended sessions related to agile (I also did a presentation, on Kanban). This was the first year that the communities selected papers for specific tracks. I really enjoyed Mike Cottmeyer's presentation in the agile track. He talked about scaling agile to the enterprise. His model included a user story level that followed an iterative agile approach, and a feature and epic level above that using a kanban approach. I was interrupted by work and missed Dennis Steven's presentation, but I understand it was similar (you can find a lot of Dennis's presentations in slideshow here).

Jesse Fewell, who founded the agile community, did a nice job with fixed price agile projects. One of his key points was that you should focus on success criteria, not on features, when defining the scope of the project. He also talked about dynamic scope; if you want to add something into the release, you have to take something else of of similar size. Size should be in terms of cost, not something more obscure like story points.

I also caught an interesting presentation titled Agile Collaboration in a Virtual World that was presented by Elizabeth Harrin, Cornelius Fichtner, and Andrew Filev. They are all members of PMI's New Media Counsel.

There was a lot of interest in agile. Some people were very new to the concepts, others had played around with it, and a few that were looking for the more advance topics that Mike, Jesse, and Dennis presented. I missed Michele Sliger's presentation, but I understand it was a great discussion of the more fundamental points of agile.

There was a lot more twitter traffic this year, including an official PMI tweeter. You can find traffic by searching for #pminac. We also used #agc11 for agile tweets. Next year, Vancouver.

New and Shiny

2011-10-12T17:26:00.001-05:00

So today I was anxiously waiting for IOS5 to be available so I could download it and play with the latest software for my iPad. I was also one of the folks that downloaded Lion the day it was released, accepting the minor compatibility problems that came with it as a cost of being an early adopter. Is there an advantage to being an early adopter, or is it just the thrill of playing with something new and shiny?

In project management, there is emphasis in some circles on having a repeatable process. We have our PMO and our methodology and all our templates. But is this always the best approach? If each project by definition is unique, should we use the same old process for each project?

I've used Kanban on a number of projects lately and been successful with it. I think Kanban still falls into the new and shiny category, but I've been figuring out how to use it. In once case, I took a project that was following Scrum...But and when I moved to Kanban saw improved delivery, better visibility, and a happier customer.

I recall about 3 years ago when I was trying to introduce agile into the organization I was working at. At the time, agile was still shiny and new, at least in some circles. There was some resistance to this approach, even though the more traditional approaches weren't always successful (that's not to say there aren't failed projects that use agile).

Some people need a lot of proof before they change their ways, others (like me) like trying things out early to see how they work. Of course, even I won't risk a new approach on a big project; I like to test things out on smaller projects first, where the cost of failure is lower. Even if you're not an early adopter or fast follower, keep aware of the trends. What's new and shiny today will be standard before you know it.

Scope

2011-09-22T13:43:00.000-05:00

I'm finishing up the development stage of a project this week. It has been an interesting road with respect to scope. I was brought into the project after the start, actually 8 weeks into the project. When I got here, I looked at how much work was planned and became concerned. Without trying to validate the estimates, I felt there was more work than we could get done by the end of the project.

I worked with the team and client and we were able to reduce the scope by about 20%. Some of this was moving stories into the next release. Some was reducing the complexity of what we were trying to deliver.

As the project progressed, we added more scope. Not a surprise; it should be expected. As the users started seeing parts of the application, they thought of other things to ask for. But here's where we ran into a bit of a jam. We added new stories, but didn't take anything out. We assumed we could absorb the additional work; it only was a couple story points a week.

With about 4 weeks to go, as I looked at our velocity and how many points we had left, I saw we had a problem. When I brought this to the business, they said "we have to have all of this, you need to work harder." Two weeks later, the business saw what I was talking about, it just wasn't all going to get done.

The business identified some stories that could be moved out. The remaining work was still more than our average velocity, so I agreed I would work the team through the weekend to get the rest of the work done. This was the first time I had asked the team to go above their normal work days, so I wasn't to concerned. If we had been 4 weeks out and expecting 4 weekends of work, I would have been concerned.

We got the work done. Our final tally was slightly higher than what I thought we could deliver right after we re-scoped the work. The real lesson to me is to make sure every time we add even a small amount of work, we make the client aware of how that can impact what we can deliver by the end of the project (their final delivery date couldn't be changed).

Interpretation

2011-08-31T18:40:00.001-05:00

I came across this picture recently. Do you see the old woman first, or the young woman? Can you see them both? I find it interesting how our perception can be different from someone else's.

Perception - a way of regarding, understanding, or interpreting something

I think the key word here is interpreting. We don't all see things the same way. We have filters based on our backgrounds, experience, education etc. It is these filters that create the interpretation. The thing is, we need to be aware of how other people may interpret things as well, or we can run into problems.

For example, as a mid-west US raised, former military officer, if a meeting starts at 9:00 AM, I'll be there at 9:00. With some of my clients, meetings start right on time as well. With other clients, a meeting scheduled for 9:00 may start at 9:05 or 9:10. There is a cultural difference in the company that is in effect here. My interpretation may be these people are rude for starting late, if I don't understand their culture. Once we start talking about outside the mid-west US, things can really change. When I'm in Egypt for example, I have to be aware of how Egyptians interpret time, not how I do. If a meeting is supposed to start at 9:00, I need to know that may not really mean 9:00 exactly.

So next time you seem to be at odds with a colleague, think about what their interpretation of the situation may be, not yours.

Agile2011 - Final Summary

2011-08-13T21:25:00.000-05:00

Agile2011 is over. The last couple days went so fast, I didn't even have a chance to update my blog until now. Over the last two days I spent a little time on the topic of design. I'll admit it's a topic I don't spend much time on, but I should.

On Wednesday I listed to a discussion on the topic by Mary Poppendieck. Her discussion was based on the book The Design of Design by Fred Brooks. The design is basically broken into 3 steps;

Understand the problem
Design the solution
Implement the design

A small team is better than an individual for design and the process is iterative across the three steps. Good design is like Wayne Gretzky playing hockey, he skates to where the puck will be.

The second design topic I heard was Lean UX by Jeff Gothelf. There's a great article that covers his discussion here, so head over to read it.

One of the themes I picked up on during the conference was the idea of building value. Design plays into this, designing a good solution. A couple speakers talked about how if we get to focused on delivering the user stories, we can loose track of what the real value we are trying to bring.

Personally, I've seen this with some of my clients. Even though we're using agile, there is still to much focus on competing the stories in the backlog without much thought about what value those stories bring to the business. It's not a question of getting all the stories completed, it's delivering a product that has real business value.

Agile2011 - Day 2

2011-08-09T19:44:00.000-05:00

Today started with the keynote address by Dr Barbara Fredrickson. Her topic was Positive Emotions. She cited research that showed how positive emotions expand our cognition, things like thinking more global, being more positive, improving peripheral vision, being more creative. This positive emotion can be triggered by giving a gift, pictures of cute puppies or upbeat music.

My next session was lead by Chet Hendrickson and Ron Jeffries. It was a retrospective of what we've done right and wrong over the past 10 years since the Manifesto was signed. On the positive side, agile has found its sweet spot, co-located, cross-functional team with solid technical practices doing frequent iterations. On the other side, there's dogmatism. This is common in people new to agile; insisting that the rules get followed. This behavior is a result of ignorance, fear, or inexperience. There's also the competition factor; do we use xP, Scrum, Crystal? There conclusion was there is plenty of bad software practices out there and it doesn't matter what you use as long as you follow the principles.

I also sat in on a session by Jim Highsmith. He was talking about the subject of leadership and doing agile versus being agile. One interesting idea he threw out was on technical debt. As it builds, the cost of change increases exponentially.

My last session today was with Andy Hunt, which would make it the 3rd author of the Agile Manifesto that I heard today. He had an interesting discussion on Refactoring our Wetware, based on his book Pragmatic Thinking and Learning: Refactor Your Wetware . He talked about how we learn, how our brain works, and how we can improve. He talked about the evils of multi-tasking. He also talked about how to be more effective. One of his ideas was a journaling technique. The idea is that you do this the first thing in the morning, before checking your email or updating twitter. You write (no computers or iPads) three pages and don't censor what you're writing, and finally, don't skip any days.

So now I have to pick out tomorrow's sessions. The quality of the talks has been great. The hardest part is selecting among the numerous choices in each time slot.

Agile2011 - Day 1 Summary

2011-08-09T08:06:00.001-05:00

My morning session was on Multi-Sensory Kanban, presented by Ravindar Gujral and Andre Dhondt. Kanban is supposed to be visual. The session discussed ways to expand beyond just your kanban board. One example that they gave was connecting the computer to some speakers and when the the build fails, it creates a disturbing noise. There was also a discussion on using timers in a pomodoro technique; get the team focused on a problem and when the bell goes off, you re-evaluate where you are and what the next steps are.

I only made part of the afternoon session due to a work-related conflict, but I did listen to a discussion on deliberate practice. Some of the key points here;

It must be designed to generate improvement

It should focus on a weakness

It should put you under stress.

It requires thought/is mentally demanding

It must be repeated a lot to achieve results

It's not fun

This session was by Tom Perry and I wish I could have listened to the rest, because it looked like it was going into how we can practice techniques to become better leaders.

The real highlight though was the evening session, which featured a Q&A session by 15 of the 17 signers of the Agile Manifesto. They provided an insightful and humorous discussion on how the manifesto came into existence.

The conference has around 1600 attendees. My real purpose in attending is to help promote the PMI Agile Certification (PMI-ACP sm). I was in the booth Monday evening discussing this with attendees. There was a lot of interest, both with current PMI members and folks who weren't active with PMI. The exam will be available on September 15th.

$300,000 bonus

2011-07-19T07:27:00.000-05:00

There was a big road construction project over the weekend in California, with predictions of major travel disruptions around the area. However, things didn't turn out as expected, and the construction company earned a $300,000 bonus for finishing the job in 33 hours instead of the expected 56 hours.

So what would you do to get a project done sooner. Is this an effective way to run your technology project?

According to Daniel Pink in his book Drive, cash incentives won't motivate the team effectively. According to Pink, "if-then" rewards such as a bonus for getting done early, aren't effective in the long run. Mihaly Csikszentmihalyi introduced the idea of flow, where intrinsic motivation takes over and the person is absorbed by the task at hand.

I recently took over a project that was "challenged." One of my steps has been to remove distractions from the project team so they can focus on the development tasks. I'm using Kanban to help with that, minimizing the work in progress and helping the team focus on what needs to be worked on next. What should happen next is their efficiency goes up because they aren't multi-tasking and they can get to that point of becoming absorbed by a single user story and get into the flow. I think it will take a couple more weeks to really know how effective my approach is, but throughput seems to be going up so far. This is good, since I don't have $300k to give the team.

Personal Kanban Update

2011-06-22T10:48:00.000-05:00

So I've been using my home Kanban board for about a month now. As I suspected, it is a bit of a challenge to use a physical board with as much travel as I do. My approach so far has been to review the board before I head out on a trip, figure out what will be in my working queue, and capture that electronically. When I get back home, I update the board. I think I have to go to an electronic version of a kanban board, but I haven't looked into that yet.

I've also started reading Personal Kanban by Jim Benson and Tonianne DeMaria Barry. I'm almost done and it has given me some other ideas.

One idea is setting up a special flow for different tasks; in my case when I do writing. My writing takes on a different flow than just from doing to done. I found with writing articles or papers, I go through a step of laying out the outline, then I go through a first draft where I try to get my thoughts on paper, a second draft where I try to make my thoughts more coherent, and a final review to check grammar, punctuation etc.

I also like the idea of having a "Today" column. That gives me the ability to look at everything I have going on that day - tasks, meetings, work in progress - and decide what else I think I can get done.

One area I still need to improve on is capturing all my tasks. Right now I am only putting the bigger tasks on the board, not all the little tasks I have going on. I think I need to do this to really get the full effect. In general though, setting up my personal Kanban has helped me get more organized.

Shuhari

2011-06-14T08:15:00.000-05:00

I've written in the past about the rules of jazz. I've come across another similar concept that has surfaced in relation to learning agile techniques; Shuhari. The ideas first gained popularity in the martial arts, but is being used these days when discussing agile. Alistair Cockburn has been an advocate of this idea (link).

Shu is the first stage, when a pupil is learning the technique. The emphasis here is practicing what was learned. This reminds me of the new Scrum Master, running their first projects following the techniques they developed in training. Having a coach would be beneficial at this stage.

Ha is where we start to think about what we've learned. We may start to bring innovation to our technique. In jazz, this is where you start taking solos and improvising. In the project setting, it is where you start bringing in new ideas.

Finally, Ri is where we discard the structure learned in the first step and take our own direction. We are no longer the student but the practitioner.

A key part of this approach is that it is a journey. As a project manager, you will face challenges if you try to move right to Ri without practicing in Shu and reflecting upon it in Ha. I have always been an advocate of selecting the right approach to manage a project based on the details of that project (a Ri action). However, to be able to do this, a PM must understand the tools in their toolkit, which they build in the Shu step. The Ha step is where the begin to understand how a particular approach works in a given situation.

This isn't a one-time journey either. I know as I adopt new techniques, I have to go through all three stages. Learning Scrum is a good example. I was already a project manager when I learned Scrum. I went through Scrum training and applied what I learned (Shu), then I started holding retrospectives with my team to reflect on how things were going (Ha), and then we modified our approach on new projects (Ri).

Adjusting Goals & Re-planning

2011-06-11T10:01:00.000-05:00

I ran the Chicago 13.1 last weekend and while my time was not very fast, I did make it across the finish line; which was an accomplishment under the conditions we faced. Because of heat & humidity, the race organizers actually stopped the race. Only about 130 people (out of 4000 starters) "officially" completed the race before is was stopped. I crossed the finish line after the clocks had been turned off.

Preparing for and running this race was a lesson in adjusting goals and re-planning. The original plan was to run the race with my son. By March, we abandoned that plan because he got an injury and wasn't able to train. So I set a new goal of running under 1:45 and targeted my training toward that goal. On race morning however, with the temperature already climbing to a humid, sunny 80 degrees before the start, I knew if I went out on my target pace, I would pay for it later in the race, so I went slower right from the beginning. I ended up about 7 minutes off my target, and I was pretty tired at the end, but I made it.

So how often does this happen in projects? We start out with a goal, and as events unfold, that goal is no longer attainable. Can you recognize the need to re-plan, or do you keep marching toward your original target, not admitting that the situation has changed and your plan won't work?

I was consulting on a project last year where it became obvious that we would miss the target date. This information was presented to the executive steering committee, but they wouldn't allow the date to change. I think their logic was that if they let the date change, everyone would start slacking off. We missed the date, but still no one tried to come up with a realistic goal. It turned into a death-march where everyone was trying to deliver to an impossible goal. Fortunately for me, I had moved on to another project by then.

Did the executives achieve anything by keeping the pressure on? I doubt it. The morale was sinking with my team members as the project moved forward. In the race, the people that didn't adjust their goals were disappointed. People I talked to missed their target by 20 or more minutes and were really suffering at the end. When faced with reality, it's better to adjust a goal to be achievable. That doesn't necessarily mean easy, but if everyone knows the goal is impossible, the race is already lost.

The 10 Year Rule

2011-05-31T07:42:00.000-05:00

When I started running, I came across a statistic that the typical world-class runner had been running for about 10 years, and that's when most people could expect to reach their peak. This held true in my case as well, but I didn't think much about why this was the case.

It turns out, it's just not for runners. In general, people will get really good at something after about 10 years of practice, or after about 10,000 hours of practice. This is true for musicians, computer programmers, athletes, and probably even project managers.

One of my favorite stories is of the basketball great, Michael Jordan. After not making the varsity squad, he became one of the hardest working players, and it was this hard work that lead to his eventual success, not some talent he was born with. There's a term for this; deliberate practice. Deliberate practice is when you are focused on your technique, not just the outcome and you dedicate a lot of hours to practice. Feedback is also important in deliberate practice, to make sure you are moving in the right direction.

So how does a PM get this? Having a mentor or coach is a good start, they can provide that feedback that is part of deliberate practice. Getting feedback from your boss is also a good idea.

A day with His Holiness the Dalai Lama

2011-05-11T21:22:00.000-05:00

I had the privilege of spending the day getting to hear His Holiness The Dalai Lama speak. He was at the University of Arkansas today as part of a set of visits around the US.

The morning session was a panel discussion on non-violence with Sister Helen Prejean and Vincent Harding. One moment that stuck with me was when Sister Prejean brought up the fact that as people watch more television, they develop more fear. His Holiness expanded on the thought by saying there are two types of fear. One fear is real, such as when a mad dog is charging you. In his humorous style, the Dalai Lama said meditating about compassion won't help you here; the dog will still bite you. The other kind of fear comes from within but it isn't based on fact.

If a problem has a solution, there is no need to be overwhelmed and if there's no solution there's no point to be overwhelmed - The Dalai Lama

The other speakers had some amazing stories as well. Sister Prejean told about the first time she met with the parents of the victim of a murder after the murderer had been executed on death row. While there is a lot of pressure for the family of victims to help support the death penalty, they don't necessarily feel this way.

Vincent Harding had a story about when a church in Alabama was bombed in 1963, killing four girls and injuring many others. He remembers people close to the event who's first reaction was to get even, people that stood for non-violence. However, they turned this feeling around and what eventually came out was the march from Selma to Montgomery.

My favorite sound bite was when the Dalai Lama said "your enemy is your best teacher." He went on to explain that we won't learn how to practice compassions from our friends. We will only truly learn how to practice compassion and forgiveness by engaging our enemies.

The afternoon session started with the University conferring an honorary degree on the Dalai Lama and a short lecture by him. This was followed by a question and answer session, with topics from the recent events in Egypt, censorship, and even the first time the Dalai Lama drove a car (it didn't end well). The real message throughout both sessions was a call to action. In order to stop violence, we can't go meditate about it. We have to go out and do something.

Snakes in the Garden

2011-05-04T06:33:00.000-05:00

There's an Arab expression "When you allow a snake to live in your garden, it will eventually come into your house." I heard it used this week in reference to Osama Bin Laden, but that's not what this blog post is about.

When I was first learning about Scrum, one of the thoughts that kept surfacing is that Scrum won't fix all your problems, but it will make them more visible, kind of like making that snake visible. The next step then would be to fix the problems (get rid of the snake). While Scrum does talk about inspect and adapt, it's really focused on the team level. Sometimes the problems you may face are bigger then that, and Scrum doesn't provide the solution to fix them.

This is where Lean can help out. A key principle of Lean is looking at the entire value stream, not just your development lifecycle. I had a conversation lately about organizations that have separate QA teams that do the testing after development. In a non-Lean organization I was working at, there was a handoff to QA after development, which resulted in a number of problems that caused delays. If we took a Lean approach, we would have worked with QA to optimize the entire process. So we failed to get the snake out of our garden.

What snakes are in your garden?

Personal Kanban - Week 1

2011-04-26T20:01:00.004-05:00

So I'm in my first week of using a personal kanban board. So far I think it's a success.

I set it up last Friday afternoon. It was a good way to wrap up the week and make sure I wasn't forgetting any tasks that had to get done before I called it a day. It also worked well when I walked in my office on Monday morning - a quick, visual reminder of what I have going on.

Here's how I set things up;

I have two swim lanes, one for work, the other for home/other projects (such as volunteer work). Within each, I set a limit of 2 items for work in progress. We'll see how well that works in a couple weeks when I'm running 2 different projects.
I use small stickies for tasks that are small, around a couple hours or less. I have big notes for more involved work. On these, I jotted down important details. For example, the task to prepare for my presentation at PMI has key dates I have to meet.
I'm going to keep things in "done" throughout the week and use this to help me do my timesheet at the end of the week.
I am still keeping a "To-Do" list of short, quick things I have to do. I haven't made up my mind on the best way to handle these items.

I haven't figured out what I'm going to do when I'm traveling. I think I'm going to use a notebook to capture what I have to do when traveling and write things down that have to go on the board when I get home. Stay tuned for updates.

Pirates and Leadership

2011-04-13T07:36:00.002-05:00

There was an interesting article in Harvard Business Review last fall about star and guardian tasks. Star tasks are those that are more strategic while guardian tasks are more operational. The article discussed how effective pirate ships were at dividing these tasks, since one person is typically not good at performing both kinds of tasks.

The world of project management is the same. The star tasks would be having a vision for the product or seeing the big picture. These are tasks often associated with the product owner or sponsor. The guardian tasks would include planning out the work, getting the right resources, or managing the budget; obviously more in line with the project manager.

So just like the pirate ship, with a captain to handle the star tasks and a quartermaster to handle the guardian tasks; you should keep these to roles separate on your project. And as the project manager, if you have a team member out of line, you can make them walk the plank.

Divisive Speech

2011-04-06T05:49:00.002-05:00

Part of Buddhist practice includes avoiding the 10 non-virtuous actions. One of these actions is divisive speech. I think this project managers should pay attention to this one.

Divisive speech can be thought of as any words that can bring disharmony or create animosity. Politicians do this a lot; trying to create a division between themselves and their opponents while making their opponents look bad.

This type of speech can happen on a project team as well. While I feel conflict can be good, if the conflict includes divisive speech, it can hurt the team. For example, discussing the merits of .NET or Java can be a healthy discussion, but when it turns to insults, there's no benefit.

A successful project relies on a effective project team. This takes time to develop. It's the project manager's job to see that this happens. It can be as simple as having some ground rules established at the start of the project that guides the right behavior. Once the team gets rolling, these rules won't be necessary but during the forming/storming stages, they can help the team move in the right direction. What ground rules do you put in place at the start of a project to ensure your team's success?

Problem Solving and Climbing

2011-03-23T18:40:00.002-05:00

This past weekend I did some rock climbing at Horseshoe Canyon Ranch in Jasper Arkansas. This was the first time I've ever done any climbing outdoors, after doing gym climbing for the past few months.

Outdoor climbing was a lot different from climbing in the gym. In the gym there are a set of holds that you follow as you climb up, all marked with colored tape so you know where to go next. Outdoors, you have to figure out where to grab and step. It becomes a problem solving activity as much as a test of physical capability to get to the top.

I thought about how this resembles the difference between taking a training class and working in the real world. A training class is like the gym, you are guided along. In the real world, you have to take what you learned in training and use that to solve problems you didn't face in the gym, or class.

As this was my first time outdoors, I have a lot to learn about climbing, just like a new project manager. It will only be through experience that I learn how to climb better. The other thing I had was a group of more experienced people to help show me the way, just like a new project manager should have a coach or mentor to help show them the way. No one can climb that cliff for me, but they can help me see the path.

Multi-tasking and Creativity

2011-03-10T06:28:00.003-06:00

I've written before about multi-tasking (here, here, and here). In general, I think multi-tasking doesn't work and should be avoided. But does it hamper creativity?

In a study done by Teresa Amabile and others (see footnote), they found that having a fragmented day (ie, multi-tasking) didn't help bring out more ideas. Focusing on a single topic and collaborating with a single individual increased creativity.

I think about my typical day on site with a client. I have multiple meetings on different topics and don't seem to get a lot deep thinking work done. On Fridays, when I work from home and have more control over my day (and less meetings), I can carve out a large chunk of time to focus on a single topic and that's when I come up with some good solutions.

I've heard of organizations that are going to no email Fridays. I think the benefits will be the same. Without the distraction of email, they can focus on a single problem and let the creativity flow.

So pick a problem you've been trying to solve, block your calendar for half the day Friday, turn off the email, and get creative.

Teresa M. Amabile et al., “Time pressure and creativity in organizations: A longitudinal field study,” Harvard Business School working paper, Number 02-073, 2002

Why the PMI Agile Certification is a Good Thing

2011-02-28T10:17:00.001-06:00

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.

Three Cups of Tea

2011-02-16T05:50:00.003-06:00

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.

Domain Knowledge

2011-02-09T05:56:00.001-06:00

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?

The Zeigarnik Effect

2011-01-25T05:40:00.003-06:00

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.

Who do you hang out with?

2011-01-21T09:37:00.001-06:00

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).

Inspections

2011-01-19T05:58:00.003-06:00

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.

A new habit - daily retrospectives

2011-01-11T05:47:00.002-06:00

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;

What were my successes and challenges?
What did I learn?
Who should I reach out to?

The 3rd question is a good one for me. The idea is to think about the people I interacted with that day. Did I promise to send somebody something? Do I want to follow up just to say thanks? Maybe there's a compliment I didn't have time to deliver earlier that day. I'm not the best networker, so this will help me make more of an effort to keep my network alive.

Out with the Old/In with the New

2011-01-03T09:08:00.003-06:00

So have you made your New Year Resolution? I heard a quote that 4 out of 5 people fail to achieve their resolutions. It sounds like we need a better plan to succeed.

For many years, fire has been used in ceremonies; from Buddhist monks or Native Americans burning prayers to the Burning Man ceremony; this has been a way to get rid of bad karma and move on. I've participated in a burning bowl ceremony, where people write down what they want to get rid of (bad habits etc) and put them in a bowl to burn. I like the idea of getting rid of something old in order to make room for something new. If we want to lose weight, we need to give up our bad eating habits.

This might be a symbolic first step, but we still need a plan if we want to succeed. This time of year I plan out my racing plans for the coming season; key races I plan on participating in, goals I want to achieve etc. Based on that, I plan out the type of training I need to be doing, down to a weekly level. As I get into the year, the plan may get modified, but I have a plan to follow, not just a vague resolution to exercise more. We need this for any of our resolutions; a plan to ensure we can achieve success. So set some goals for the year (resolutions) and plan out how you're going to reach them. What are you doing this week to help reach those goals?

More on Culture

2010-12-20T11:48:00.001-06:00

As I mentioned in my last blog post, one of the presentations at last week's P2P was on the challenges of implementing Agile in the Egyptian culture. Since I'm working with a team in India, I wanted to take a look at how Indian culture aligns with Agile.

One area of consideration is that of the self-organizing team. Indian culture supports team work. However, there is also respect for hierarchy, so the team may not feel empowered to make decisions. The team may feel the need to defer to a senior person for decisions. I have found that I am being asked to make more decisions compared to a US based team.

Indian culture also tends to avoid open confrontation. I think some conflict can be good as the team is developing. On my US-based teams, it isn't unusual for one developer to provide constructive criticism to another's work. This type of feedback should be delivered with a softer tongue for my off-shore team.

Another area that I have noticed relates to communications. Indian culture puts more emphasis on written communications. I know my off-shore teams have often asked for more formal requirements documents than what I expect from a US based team. One adjustment I've had to make is to provide more documentation for my off-shore team to work from.

Indian businesspeople tend to be tough, smart negotiators. While this conflicts the idea of customer collaboration over contract negotiation, successful negotiation is built on trust. However, building this trust can take time. In my case, I had time to start working on building that trust before the project work started up.

So what does this really mean? First, my points are just generalizations. For anyone working with other cultures, this type of understanding is just the starting point. You shouldn't rely solely on generalizations for determining how to work with your team any more than you would use New Yorkers as a benchmark for working with Americans from other parts of the US. For any cross-culture work, take the time to know the people you are working with.

Projects to the Point 1st Impressions

2010-12-13T21:39:00.002-06:00

Day 2 of Projects to the Point has wrapped up and so far it has been an interesting conference. One of the themes of the opening day was change. Emad Aziz from Brisk Consulting talked about how change is the only constant. As project managers, this is what we have to deal with. Related to that, Dr Mohamed Tewfik Elmasri talked about organizations that are transforming (such as through a merger/acquisition) and how a key part of the change management process is communications; "People can deal with bad news, people can't deal with uncertainty."

Another interesting presentation was by Ali Zewail and ElMohanned Ahmed. They discussed the challenges of implementing agile in an Egyptian company from a cultural perspective. They even compared the principles of the Agile Manifesto to the cultural attributes of Egyptians. It made me think about my team in India and how agile aligns or conflicts with some of their cultural characteristics.

Motivation

2010-12-08T20:44:00.002-06:00

I was re-reading parts of Daniel Pink's Drive in preparation for one of the presentations I am giving next week at Projects to the Point in Cairo. My talk is on what makes a good leader for agile projects and his book fits in good with his thoughts on motivation.

In the book, Pink sites why the "carrot and stick" approach to motivation doesn't work. You can read the book for the details, but in summary, this approach tends to drive the wrong behavior, only works in the short term, and kills creativity.

So what do you do to motivate people? There are three things people need to be intrinsically motivated; autonomy, mastery, and purpose. Autonomy is letting people decide how they accomplish their goals, or even what some of their goals are. Mastery is becoming an expert at what you do. Purpose is knowing that what you do has some higher purpose than just adding to the bottom line of a corporation.

One example that brings this home is the battle between Microsoft's Encarta and Wikipedia. Microsoft used money to motivate people to build their encyclopedia while Wikipedia was build by a bunch of volunteers. Encarta failed while Wikipedia is extremely successful. So if you have a team to motivate, money isn't the answer, nor is a autocratic leadership style. Providing them the tools they need to succeed, giving them the freedom to use those tools how they want, and providing a vision for what is needed are going to get you closer to your goal.

Organizational Multi-tasking

2010-11-17T05:53:00.001-06:00

I had the opportunity to talk to Sanjeev Gupta, the CEO of Realization last week. His company is applying the principles of Critical Chain to help companies out.

We talked about multi-tasking; one of my favorite topics. I often think of multi-tasking at the personal level. If I have one of my developers working on 2 different tasks at once, they are less efficient at both and loss time to context switching. Sanjeev pointed out the organizations multi-task as well, something I don't think about as often, but in hindsight, have observed frequently.

This situation occurs when organizations are trying to run to many projects at once. Teams are getting pulled back and forth; again resulting in all the projects coming in later than they could if a more focused approach was taken. Sanjeev often recommends to clients that they cut back on the number of active projects going at one time. It made me think of Kanban, but at an organizational level; you pick the most important project and get it completely done before starting the next.

The other part of effective delivery from Sanjeev's perspective is ensuring everyone knows the priority of the work at a task level. This is the project manager's job to drive this message. So instead of having a complex project plan with resources assigned to multiple tasks (with no priority), you provide each resource a prioritized task list and have them focus on the highest priority first. Just like having a prioritized product backlog.

So does everyone on your team understand the priorities? Do you find them working on tasks that may not be so important? At an organizational level, does everyone understand the priority of the projects?

The Importance of Design

2010-11-09T06:08:00.003-06:00

In A Whole New Mind, Why Right-Brainers Will Rule the World, Daniel Pink sites 6 key areas that will help us master right-brained thinking; Design, Story, Symphony, Empathy, Play, and Meaning. I plan on going into each of these, starting with design.

One example given in the book is when school children are asked if they are artist. In first grade, everyone says yes, only a few say yes in third grade, and none by sixth grade. As the education process evolves, we teach our children to focus on left-brain thinking and the creative side is pushed out.

However, the need for good design is growing. I'm a fan of Apple products. I watched yesterday as a colleague opened a new iPod Touch. Even the packaging was well designed. Apple knows that enough people are willing to pay extra for good design to make them successful.

So how does design play into a project manager's life. Do you prepare a lot of PowerPoint presentations? Have you read one of the books on good PowerPoint design such as Presentation Zen or slide:ology? A well designed presentation will go farther in communicating your point than a poorly designed set of slides will.

There are other areas where design can play into your role as a PM. If you're delivering any kind of product, you should be thinking about design. Even if someone else is responsible for that aspect, you should still know what good design is. Even the way you're team's workspace is designed can impact their productivity.

Moving to the Right

2010-11-02T04:46:00.003-05:00

I'm currently reading Daniel Pink's latest book, A Whole New Mind, Why Right-Brainers Will Rule the World. The book is based on the premise that just like manufacturing jobs went overseas, so to are the more analytic tasks associated with our left-brain; things like computer programming or accounting. So in order to succeed in this coming age, we have to tap into our right brain; the creative, holistic, intuitive side.

Pink sites three reasons for this change; abundance, Asia, and Automation. Abundance can be seen be going to the local Target store; affordable designer products down every aisle, from clothes to kitchen utensils. In the US, there are more cars than registered drivers; no shortage there.

Asia of course refers to the cheaper labor available to perform those left-brain tasks overseas, whether it be India, China, or the Philippines. These countries are producing plenty of people that can perform these tasks, though it isn't limited to just Asia. Eastern Europe, South America and other countries with low labor rates/cost of living are jumping in. According to one survey, one out of four IT jobs will be offshored by the end of this year.

Automation is the final factor. Computers can do work that people performed not that long ago; from playing chess to doing your taxes, to even programming computers. Think about the act of creating a legal document. You no longer need a lawyer, you can tab into a web site for much cheaper today.

The answer for us is to evolve, learn to use our more creative side to help us succeed. So in a project context, it's no longer good enough to make sure the programmers are producing software that meets the requirements. We need to become engaged with our customers in order to create something more. Pink talks about high concept and high touch. High concept can involve detecting patterns or combining what may appear to be unrelated ideas in order to create a unique solution. High touch involves understanding the subtlety of human interaction.

In my next post, I'll explore some ways that Pink discusses to move in this new direction. For now, ask yourself these questions about your work; 1) can someone overseas do it? or 2) can it be done by a computer? If the answer to either is yes, you need to start thinking about your future.

PMI Central Iowa PDD

2010-10-15T17:27:00.004-05:00

I was going thru conference withdrawal after leaving the PMI Global Congress on Tuesday, so I headed up to Des Moines for the Central Iowa Chapter's Professional Development Day (actually, I was invited to speak). As compared to the PMI Global Congress, this was much smaller (about 350 attendees compared to around 3100). However, the organizing team did a good job of recruiting some pretty good speakers.

The opening speaker was Kevin Hall. His talk focused was titled "Transforming Your Purpose Through the Power of Words" which is based on his book Aspire. One of his words that I liked was "genshai" which he defined as never treating someone in a manner that makes them feel small.

The other speaker I got to see before I spoke was Lisa DiTullio, who talked about career resilience for project managers. One of the points she made that stuck with me was the idea of self-promotion. How are you promoting your accomplishments in your organization?

In all, a good way to wrap up the week. Next week, it's back to business with a few new tools in my toolkit...or as Stephen Covey would say, I've spent some time sharpening my ax.

Final thoughts - PMI North America Global Congress

2010-10-13T21:32:00.003-05:00

Well I'm back home after the PMI Global Congress in Washington DC (well, actually Oxon Hill Maryland). As with most conferences, there were some good presentations and some that didn't really impact me. Some of my favorites from this year were:

Jesse Fewell on Modern Agile Contracts. He had some new ideas on contracts and was able to make what could have been a dry topic interesting
Michele Sliger's Goodbye Scope Creep, Hello Agile.
Jeff Ottman and Dr Preston Smith on extending agile beyond software development.
Richard Sheridan's The Keys to a Sustainable Work Pace
Elizabeth Harrin on social media for project management
Dr Thomas Juli on collaboration tools

I consider a presentation good if I walk away with 1 or 2 ideas that I can apply back at the office. It also helps if the presenter knows what their doing. Dr Juli wins the award for best slides. He is a fan of Slide:ology, but the ideas are similar to Presentation Zen which I am a fan of. The better presenters also managed to have good levels of interaction, in spite of the size of their audience.

It was interesting to follow the twitter feed throughout the congress. Oddly, it seemed I knew most of the people tweeting. Does that say anything about the type of people I hang out with?

The real benefit of an event like this is the networking. This event was no different. I re-aquanted with old friends, got to know some people I had met in the past better, and met some new people (some that I knew through twitter/blogs etc already).

PMI Congress - part 1

2010-10-11T13:38:00.003-05:00

The PMI North America Congress began yesterday. This year there are a large number of agile tracks. PMI VP-IT Frank Schettini has been introducing the agile speakers to help spread the message that PMI does support agile.

Yesterday's keynote was Bill Clinton. While I didn't agree with his politics while he was in office, he kept his presentation relatively politic-free. At the end of the session, Greg Balestrero asked him what his hopes for where for the country in 5 years.

President Clinton said there were those hopes that we can't do anything about, like I hope it's a nice day tomorrow. Then there were hopes that should tell us what we should do with our lives. So if you hope for a better world, what can you do to help bring it about. When our founding fathers wrote the constitution, it was with the idea that we would never be perfect but that we should always be striving to getting better.

The Zen of Kanban

2010-09-22T05:19:00.002-05:00

I'm using Kanban on one of the projects that I'm overseeing right now. It seems to be a perfect fit for this particular project.

Kanban came from the Toyota Production System (TPS). The idea is that you don't stockpile parts, they flow as you need them to the production line, minimizing your work in progress. If you want to read more about Kanban and software development, here is a good article.

On this project, the product owner had already pulled together some requirements before we stepped in. Our first step was to organize the requirements into a backlog and get him to prioritize the work. Then we asked him when he wanted the next release to be ready.

We did some high level estimates and then cut the backlog in half, saying we thought we could get through half of it by the release date. That was the first step to reduce our work in progress.

I have two developers on the project, so they each picked a feature from the top of the list and got working. They did some more requirements gathering, design, and build and unit test...keeping the product owner involved throughout the cycle. They then did a demo for the product owner, getting his approval that the work was done. At this point, these features were ready for final testing (by another group), and the developers picked more work to start on.

What has really made the Kanban approach work well here is that the team was small, the work could be timeboxed, and the product owner was involved and flexible about how the work was delivered.

Like Scrum, Kanban doesn't dictate specific software engineering practices. In this case, the developers are following some standard practices that we use on other projects and I have another team member doing code reviews as part of our QA process. The final testing is being done be another group in the organization and because that decision was made after the project got started, we don't have them looped into the Kanban approach. We are planning an iterative approach to testing, so they aren't waiting for all the work to be done before they start. We'll have to work on better integration of the testing approach on our next project.

So if you have a small project (maintenance releases work well) and want to try something different, consider Kanban. I've found that focusing on one or two features at a time make the team more efficient at getting the work done.

When to Multi-task

2010-09-01T05:56:00.003-05:00

One of my LinkedIn Groups had a discussion this week about multi-tasking, sparked by an article in InfoQ. The article talked about the cost of context switching and some of the other costs of multi-tasking. There conclusion, which I generally agree with was;

Context switching between projects takes time and is a cost to the organization. The more projects involved and the more complex the projects, the higher the cost. By focusing on one thing at a time for a longer time period, individuals can work more efficiently.

So is there a time when multi-tasking is ok? The answer is Yes. Harvard Business Review had a recent article on this topic and they sited a couple instances when multi-tasking could help you.

One idea that struck a chord with me was to multi-task when you are stuck. If you're trying to solve a problem and can't make any progress, step away, go do something else, and come back with some fresh ideas. I do this a lot with work...if I feel like I'm not getting anywhere, I'll go get a cup of coffee, talk to a colleague, or even surf the internet for a few minutes. When I get back to the original task, I've come up with an idea that gets me past my roadblock. Next time you're stuck, try it.

Beyond Do's and Don'ts

2010-08-25T05:38:00.004-05:00

Being involved in multi-cultural, cross-border projects is much more common these days than it was the past. So how has our ability to work effectively in this environment evolved in recent history?

I can recall the first project I had in a foreign country. I did what a lot of people did, I learned what you should do and shouldn't do in that country. For example, in an Arab country, it is considered impolite to shake hands with someone using your left hand (a "don't"). Similarly, in India, where it is common to eat with your hands, using your left hand to eat is also considered impolite.

So while learning the do's and don'ts will keep us from making a fool of ourselves, we need to go further to work effectively with these cultures. Some areas to focus on include;

Problem solving - does the culture you are working in put more emphasis on facts or on logic/reasoning? Do they come at the problem from different angles or try to focus in on just one solution?
Governance - how is power shared or controlled? Are people punctual or not? How do they approach risk?
Relating - are tasks more important or relationships? Are individuals or groups more important? Are communications explicit or implicit?

Understanding the answers to these questions will help you understand how you should work with other cultures. If you know a culture appreciates explicit communications, you will know to get to the point rather than indirectly address an issue. So next time you are going to work with another culture, take the time to get beyond do's and don'ts.

Technical Debt

2010-08-15T07:56:00.002-05:00

So I started a new program a couple of weeks ago. Typically I get involved with new clients and help them build their first set of business processes using our software. This project is different, the client has been using our software for a number of years and part of my job is to take of the operations/maintenance of a number of applications.

As my team started looking at these existing applications, they came across a lot of "technical debt." The applications were developed and enhanced by a number of different developers with different skill levels (some with low skill levels for working our our products). So we have a lot of code that's going to be hard to maintain and enhance.

It's a tough situation. The client uses a charge-back system to charge the business units for development, so we don't have money to just go in and completely re-factor an application, even if it needs it badly. On the flip side, both new enhancements and maintenance take longer because of the debt we've inherited.

For now we're going to have to live with it. We'll try to pay off the debt slowly by cleaning up parts of the code as we do our development or maintenance. I think the client is starting to realize the cheap solution for development wasn't necessarily the best.

Got a story to tell?

2010-07-21T06:49:00.003-05:00

I started work with a new client this week. One of our conversations revolved around adoption of the program we were implementing. This is a pretty common theme in a lot of projects I work on, how to get people to buy in to your vision.

I came across an article on this topic on Harvard Business Review. One of the interesting recommendations of the article was to tell stories. As a former Navy guy, I have heard my share of sea stories. While entertaining, sea stories also had a lesson to teach. It was usually about how to avoid doing something stupid, exemplified by someone doing something stupid.

But stories can help in business as well. I often tell stories of how a previous client did something similar and what their outcome was. Sometimes, in spite of my best advice, I have had clients do stupid things. More often though, they stories are of success. The story drives a point home better than providing statistics or giving recommendations without any backing.

So what stories do you have to tell? How will your stories help you move your project forward?

A Brand Called You

2010-07-16T08:56:00.001-05:00

I had an article published yesterday on Projects@Work on Seth Godin's latest book, Linchpin. I've been a fan of Seth Godin since he spoke at the PMI Global Congress more years ago than I want to think about. It was at the conference that I was introduced to Fast Company magazine as well.

From Fast Company's "The Brand Called You" to Linchpin, the focus has been on how you need to take charge of your future. So have you worked to refine your brand? You may be thinking that you don't need to because you work for a company and don't plan on becoming a free agent. Even if you do work at a company, you still need to think about your brand. As Godin points out, if you are just a cog, you can be replaced by a cheaper cog.

So where do you start? One good technique is to become the expert on something; be it project management, your company's products, or some technology. Then you need to get the word out that you are the expert and help people out. This is what Godin calls giving your gift.

As an example, I was one of the first people to get my PMP certification in the organization I was working in at the time. I started helping other people get a better understanding of project management. First, it was some half-hour "brown bag" sessions at lunch and eventually I put together a half day intro to project management for people in the department. This wasn't in my job description. No one asked me to do it. I did it because I was developing a passion for project management and I wanted to share it. People started to think of me as the guy who know how to run a project, and the big, high profile projects started coming my way.

So figure out how to brand yourself. What do you have to offer your organization? What problem do you want to be known for solving?

A good quote

2010-06-21T20:37:00.001-05:00

A came across this...it's like the saying the race doesn't go to the swiftest but to the one that keeps on running;

“Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination are omnipotent. The slogan ‘press on’ has solved and always will solve the problems of the human race.”~ Calvin Coolidge

Are things getting to complicated?

2010-06-18T14:35:00.003-05:00

I heard an interesting tidbit of information this week. As software complexity increases, the amount of effort to add a feature rises exponentially. For example, if you were 40 story points, it might cost $10,000 (I am making all these number up) but to do 80 story points wouldn't be $20,000 but more like $40,000.

So when you combine this with the Standish study that said only 20% of the features on custom developed software are used always or often, you have a pretty good argument for simplification. Not only do all these extra features never get used, they cost a whole lot more to implement than the basic features that are needed.

So next time you're in front of the customer and they ask if you can do this or that, say yes, but it will cost them. Ask them what the real business value is. If they have a good answer, the feature probably makes sense. Otherwise, focus on the top 20% of the features they want (based on business value) and deliver that first before committing to any additional work.

Are you being creative?

2010-06-10T07:32:00.004-05:00

Back when I was in the Navy, I received one fitness report (aka performance evaluation) in which I had a lower rating for Creativity. At the time I was puzzled, why would I have to be creative? I was a low-level officer, just following the orders given to me. There wasn't any room for creativity in my job.

It took me a while to realize that in any job you should be bringing creativity. Following the rules is not enough. You need to use your creativity to change, improve, and maybe break the rules in order to improve the organization.

This isn't always easy. You have to make the time to come up with creative ideas. On a recent project of mine, I was so busy going to meetings, responding to emails, and just getting tasks done that I wasn't being very creative, so I got into the habit of reflecting on the day after I got back to my hotel room each night and thinking about what I could have done that I didn't even have time to think of during my busy day. That became the first task on my list for the next day, so I could get to it before things got to crazy.

So where can you be more creative? Take some time at the end of your work day to think about this.

Re-imagine your failures

2010-06-04T15:49:00.002-05:00

I read an interesting concept today. This come from US Snowboarder Shaun White. He said that when he doesn't succeed with a maneuver, he watches the video, then he imagines the scene but instead of failing, he succeeds with the move.

Think about this. You had a meeting or conversation with a colleague that didn't go how you wanted. What could you have done to make it come out the way you wanted?

I find I'm challenged when I have to give constructive (ie, negative) feedback to a team member, the conversation doesn't always go the way I want. If I practice Shaun's advice, future conversations should go smoother and I can get my gold medal!

Change what you're passionate about

2010-05-28T10:13:00.004-05:00

I came across an interesting idea in Seth Godin's Linchpin

Transferring your passion to your job is far easier than finding a job that happens to match your passion.

I've read a lot lately about how you should figure out what you're passionate about and then find a way to make money at it. I think about photography, which is something I am passionate about. Would I feel the same way if I had to do it to make money?

The alternative that Godin is proposing is to become passionate about what you're doing now and that will in turn make you more successful because you bring your full self to work.

Graduation

2010-05-17T06:59:00.003-05:00

My niece graduated from KU School of Journalism this past Saturday. The keynote speaker talked about 1988, the year most the students were born. I started thinking about how much journalism has changed since then. This was pre-web. Not many people even had home computers back then and newspapers had no idea what was coming as far as the changes in their industry. The professors must spend a lot of time updating their knowledge so they can send graduates out with the latest skills, but that won't be enough. The new graduates will have to continue to keep their skills updated if they want to remain competitive in the workforce.

How much time are you spending updating your skills? Stephen Covey talks about taking time to sharpen the saw; stepping back from the day to day work and focusing on your skills. Finding the time to do this can be challenging, but the options are also increasing. Now we can attend a 1-hour webinar on a topic of interest. We don't have to take 3 days off and attend a conference just to pick up some new knowledge. There are other on-line training opportunities, self paced classes, and of course books, blogs etc. What you need to do is make the time. Block off an hour or two this week to sharpen your saw so you can keep up with the changing world.

Anatomy of a project delay

2010-05-07T13:19:00.003-05:00

So I was playing a small part on a large program not to long ago that was marching to an impossible date. Late in the game, the senior executive decided to push the roll-out date by a month, recognizing that the original date was not achievable.

So my first question was, why did it take so long? I can understand keeping the pressure on, but I think there's a difference between an aggressive date and an impossible one. In one case it will motivate you to work hard, in the other, it will only discourage you. Did this decision maker not have the information needed to make an effective decision? Were people afraid to provide the information?

Of course the throw more bodies option was used at one point prior to the delay. Anyone who has tried this knows that this approach doesn't really work. Nine women can't have a baby in a month and you can only divide up a project so much before you're spending more time on overhead then on development, not to mention the increased complexity of communications.

I've seen a number of huge projects that go down in flames and every time I see a new one starting I have to wonder why. In some cases it may be necessary, but in many cases a better option might be to break the big program down into more manageable chunks. This will reduce the overhead, communications challenges, and impact to the organization.

Done

2010-05-06T06:36:00.002-05:00

So this week I introduced my team to the concept of done and done-done. I first got this idea from Dave Prior. Done means the developer thinks they've finished the task. Done-done means someone else has verified the task is really complete; such as a tester saying it passed testing or and end user verifying it is what they need.

This becomes important when you are trying to accurately track your progress. If a developer says they're done but they forgot something or it doesn't work right, there's still work to do. You may be nearing the end of your iteration and have a lot more work left than you think if you have a lot of tasks in the done stage but not really done-done.

So I don't even try to get % complete estimates I have found these to be notoriously inaccurate. I ask the developers to tell me either not started, in progress, done, and done-done. For those tasks in progress, I look for when they will be done. The tasks are all pretty small, around 8 hours of effort. That way, if I don't see at least some tasks getting done (and done-done) each day, I know I have a problem.

Agile is about being able to identify when you have problems as early as possible so you have more time to fix the problems. Having an accurate status plays a strong role in knowing the health of your project.

Rules of Jazz

2010-04-20T07:05:00.003-05:00

My kids are both into jazz. They have a pretty good program at the high school they both attend. I heard someone talking about the rules of jazz recently;

Learn the rules
Practice the rules
Break the rules

The idea with jazz of course is to improvise, but that doesn't mean play which ever notes you want. However, it does mean you aren't just playing the notes written on the paper.

This is also the idea to having an adaptive project management approach. First, learn the rules. Get your Scrum certification, read some books, or attend a conference. Apply what you learn on your projects. I've talked to a number of folks that say the way to implement Scrum is to first do it by the book (rule 2).

Once you get to know what you're doing, move on to rule 3. Every project is unique, so figure out how to break the rules for your project. Again, it doesn't mean drop everything. It means knowing how to improvise without throwing the whole structure away. Have you had your jazz today?

Don't have a backup plan

2010-04-06T22:10:00.003-05:00

I'm still working my way through Seth Godin's Linchpin and came across another good idea. Don't have a backup plan. If you do, you could give up easily on your idea because of the backup plan. You know you have a fallback position, so you fall back instead of fighting. Rather than having a backup, keep pushing on your main plan until you are either successful or you truly fail, and if you fail, learn from it.

Passion

2010-04-01T20:20:00.003-05:00

One of the other books I'm making my way through right now is Seth Godin's Linchpin. The book is about making yourself indispensable so your company can't do without you because you're so unique and valuable.

One of the topics is passion. I recall when I was interviewing for the job I have now, one of the interview questions was "what are you passionate about?" Of course I said project management.

The idea here is that if you're passionate about something, you are going to work on it not because you're getting paid but because it's important to you, the end result is you become a linchpin.

So my question to you...are you passionate about what you are doing? If not, how can you find the passion?

Are you part of the problem?

2010-03-26T07:08:00.002-05:00

I am reading Karen White's book, Agile Project Management, A Mandate for the 21st Century. She uses the term adaptive problems to describe the types of problems our projects are meant to solve. I've see this term used before, it means our problems can't be solved by our traditional tools; we have to adapt out tools to meet the specific problem. Applying our standard approach just won't work on the complex problems of the 21st century.

This can apply whether your using agile or a more traditional approach to your projects. If you blindly follow a standard approach, you may be creating problems rather than solving them. We have to admit that we don't know the answer and be willing to learn as we progress through the project.

I've seen this with one of my clients. They were following agile and all the ceremony associated with it. They had their stand up meeting, iteration planning meeting, and even their retrospective, but I didn't see their approach evolve as the project progressed. The retrospective became a thing they had to do, because the methodology said so, but it wasn't helping them learn and adapt on the project.

So where do you draw the line? You don't want to throw the baby out with the bath water; abandoning the things that are working, but you have to be willing to adapt and fix the things that don't work. This is where you need to be a leader and help the team adapt while focusing on delivering the value your project was undertaking to deliver.

For example, if you are measuring progress through story points and you drop in the number of points you deliver from one iteration to the next, you need to figure out why and adapt so that next time you deliver more. So how are you helping your team evolve today?

Vacation

2010-03-19T07:05:00.002-05:00

I took a few days of vacation this week. We took a family trip to Chicago. I was almost able to completely forget about work and just enjoy myself. Now I'm back at work with a little more motivation.

There was an interesting article in the March issue of Wired. It talked about how distractions such as Twitter or Facebook can actually make us more productive at work, especially when doing creative tasks. These distractions help our mind break out of a single mode of thinking, especially when they involve activities that bring about some novel information.

When I use Twitter, it's usually to find what other people are reading or writing about, some new article about Agile or Kanban or Personal Branding. According to the article, by looking through this other material, I may unlock some idea in my mind to solve some problem that I'm currently working on. So next time you're stuck, pull out that article you've been meaning to read for the last 3 months, it may help get you through your impasse.

Evolution, Revolution, At the Edge or Out of the Box

2010-03-12T07:34:00.003-06:00

I'm reading Seth Godin's Free Prize Inside. The book is about marketing and how to get your product out to the edge so that you have differentiation from everyone else. Being a little faster, stronger, taller won't help because then it will still be a battle just on price. He uses Trader Joe's (my favorite grocery store) as an example. They don't have stuff cheaper, they have really good stuff at a lower price than brand names because they have their own label.

So I contrast this idea of going to the edge to the project I am on. We are automating a number of manual processes, but because we also have a tight delivery timeline, one of the project themes is "evolution, not revolution." In other words, we'll look for some simple improvements but we aren't trying to re-invent the organization.

One of the criticisms of this type of approach is that is stiffles that ability to think outside the box and come up with that idea that will really set you apart from the competition. So how do you decide if you should aim for evolution or revolution? The Kaizen approach would say make the small improvements, but what is your competition doing. Did Apple set out to build a slightly better MP3 player when it invented the iPod? Can you afford to make yourself just slightly better? What is your competition up to?

Pecha Kucha competition

2010-03-04T06:26:00.002-06:00

The PMI Agile Community of Practice is running a Pecha Kucha competition, “Confessions of an Agile Project Manager”.

Submit your own video in a Pecha Kucha format telling us your story. Perhaps it was a guerrilla project conducted quietly so as to deliver value without attracting too much attention, or maybe it was an organizational transformation. Whatever your experience, we want to hear from you, the community, about your experiences using Agile.

Anyone can submit and vote on their favorite, you don't have to be a member of PMI or the Agile CoP. Most importantly, we will have cash prizes for the three best submissions!
Submissions can be made to the PMIAgile YouTube group .

Rules
Dates:
- March 5th: Contest officially begins
- May 10th: Last day to submit videos
- May 17th: Last day to vote on videos
Prizes
- 1st Place: $1000
- 2nd Place: $750
- 3rd Place: $500

Participation
Anyone is eligible to submit and vote on videos

Video Format
Submitted videos should be in formatted as pecha kucha presentations. This is a power point (or similar presentation capability) showing 20 slides that auto-advance every 20 seconds, for a video that is 6:40 in length. Videos that deviate from this format significantly, while impressing us with their creativity, will not be considered for the competition.

Science Fair

2010-02-24T06:58:00.002-06:00

I'm at my company's annual kickoff this week. One of the things we do that is always interesting is Science Fair. Everyone has the opportunity to build a project, something they think our software can do that currently isn't in the roadmap. There have been some projects from past years that have made their way into the product. It's a good way to take advantage of people's intrinsic motivation.

I just finished the book Drive, by Daniel Pink. The book focuses on motivation. In the book, the author talks about other companies that do something similar. At Google, people get to spend 20% of their time on projects they want to. Many of these have made it to products. Atlasian software has "FedEx Day" where people are given 24 hours to come up with something, so called because people must deliver overnight (Side note - Atlasian's Jira tool came out as one of the top agile tools in VersionOne's 2009 State of Agile Development survey).

People get intrinsic motivation through autonomy, mastery, and purpose according to Daniel Pink. Autonomy is getting to choose what, when, and with whom they work with. In our science fair, people get to work on teams if they chose. Mastery is getting good at what you do, through such things as "Goldilocks tasks" that are hard enough to challenge but not so hard as to seem impossible. The purpose is why the company exists, something that everyone should relate to.

These intrinsic motivators will drive people and organizations much more effectively than the old carrot and stick approach, which we're all used to...if I hit my utilization target, I get a bonus. The carrot and stick can backfire in a number of ways, including stifling creativity. Things like FedEx Days or Science fair, on the other hand, will bring out creativity in a group of knowledge workers, leading to new products or services. So what's your organization doing to promote creativity?

More is not better

2010-02-17T19:31:00.002-06:00

Have you ever been on a project that is falling behind, so someone up the food chain decides you need more people and then you fall even farther behind?

One reason for this has to do with communications. The more people you have on a project, the more communications channels you have. Two people, one channel...10 people, 45 channels. Agile works because you keep the teams small and keep everyone in the same room (ideally), minimizing the amount of communications you need.

Joel Spolsky recently wrote an article in Inc on this topic. He mentions the team responsible for the main menu for Vista at Microsoft, 43 people in all, or 903 communcations channels. In a year, only 200 lines of code were written because so much time was spent coordinating.

So what do you do? Think more about your communications. Don't invite people to meetings who don't need to be there. Don't send email to large distribution lists. Take a little more time planning your communications instead of blasting it out to people just to keep them in the loop.

Requirements

2010-02-14T17:29:00.001-06:00

I had a requirements document sent to me this week to review. It was a piece of art! The document was about 100 pages long. It was prepared about 3 years ago and has sat on a shelf until now. Now it's time to start planning the project.

The first step was to ignore most of the document. My approach to move forward will be to look at the high-level business process and come up with a rough estimate on how big the project is. Then my team will engage the process owners to start drilling down into the requirements as we start building the process. We'll have regular reviews, and probably in 2-3 months, we'll have the process ready to deploy.

I think of how much waste went into this document. First, there was the time to try to document everything. In all likelyhood, a lot of what was documented doesn't really need to be in the final system. Then the document sat and gathered dust. Any Lean advocate will tell you to avoid work in progress. Regardless of how the requirements were being captured, it shouldn't have been done until everyone was ready to start on the project. Finally, there was my time trying to read/understand the requirements. As typical, it was written standard requirements-speak "the system shall provide the capability to..." and then followed by use cases that provided the same information in a more confusing manner. I could probably summarize the whole thing in a dozen user stories.

I'd like to start a reality show like "What not to Wear" expect about project management. Each week it would look at a different project and help get the project moving in the right direction. I'll have to think of a good name.

Burndown Charts and Student Syndrome

2010-02-03T06:51:00.002-06:00

I have a client that has a tendency to get nervous about half way through each iteration because the burndown chart isn't tracking. Each member of the team is giving a daily estimate of how much work remains. The catch is, each one is accounting for some uncertainty in testing/integration, so they are padding their estimates with a buffer.

The problem with the buffers can happen in agile or waterfall projects. I can remember the old days of project management...I would be working on the schedule. I'd go to the various team members and ask them how long their tasks would take. They would add in a "fudge factor" to account for any uncertainty. Then when it came time to do the work, they would procrastinate on starting, knowing this buffer was there. However, when they did start (later than they should have), they would come across the uncertainty and now their buffer was gone and the project got behind schedule. This phenomenon was referred to by Eliyahu Goldratt as Student Syndrome.

The trick of course is not to put the buffer into each estimate in the first place. In my client's case, what has happened over the last couple interations is that all of a sudden at the end of the iteration, everyone gets their work done, doesn't need the extra buffer, and the burndown takes a sharp nosedive. The only real issue is that the PM taking unnecessary steps during the iteration to try to fix a problem that doesn't exist (and try to explain what is happening to management).

Personal Retrospectives

2010-01-22T06:39:00.002-06:00

If you're following agile practices, you're conducting retrospectives...at the end of each iteration, the end of each release etc. You are inspecting and adapting your practices as you move through the project.

But how often do you do a personal retrospective? Are you reviewing your performance to see how you can do better in your role, whether you're the project manager, product owner, or a team member?

My company does quarterly reviews to see how we are tracking against the goals we set out at the start of the year, but even that isn't often enough. It's hard to remember what I did 3 months ago.

My solution is to sit down once a week or so and take time to journal. I use this as a way to reflect over what I've been working on and identify things that I could be doing better. It's an effective technique; I set some goals in writing and then review those goals on a regular basis. I can see if I am making progress or if I need to set a new direction. I've been doing this for a few years now, so I can look back at old journals to see if I'm facing the same challenges I've had in the past.

Give it a try. The only things you need are a notebook and a pen. I like to get away from my computer when I do this, but you may choose to use your computer instead. Make sure you can avoid distractions...turn off the phone and the IM. Take a few minutes to relax and take some deep breaths and then write whatever comes to mind. Sometimes my thoughts seem random but they usually lead somewhere.

Tracking Value

2010-01-15T07:19:00.004-06:00

Last night I spoke at the Agile KC (Kansas City) meeting. I was talking about the challenges of moving to agile when you're in an environment that seems content to do things using traditional approaches. I enjoy these meetings because it's a good blend of folks coming to learn and experienced people sharing with the group.

One idea that was brought up had to do with measuring value. The technique involves assigning value points to each feature or user story by the product owner. For example, the most important feature may get 10 points, some minor feature only gets one point.

As features are delivered, you track the points to show how much value is being delivered. So if you look at the graph below, you see for the first few iterations, the value goes up pretty quick but then it levels off. Since you're not delivering much value by the fourth or fifth iteration, you should consider ending the project and moving on to another project that would be adding higher value.

Personal Branding for Project Managers

2010-01-06T06:45:00.003-06:00

I came across a blog post by Dan Schawbel on personal branding trends for 2010 that I found interesting. If you haven't read Dan's Personal Branding Blog, you should take a look.

The quote that stuck with me was this;

You will be judged on voice, not just your resume
Most people judge others by their resume. A resume is an account of what you’ve accomplished in the past and an attempt to show a prospective customer what you’re capable of in the future. Sorry to say that a resume won’t be powerful enough to build your brand in 2010. In addition to all that work experience and all of that credibility you’ve built up, your online conversations will be just as valuable. If you don’t blog or comment on blogs or at least update your status on social networks, then you won’t be perceived as a valuable contributor. Your opinions and thoughts is what people will want to hear in 2010 and beyond, not just previous projects that get outdated really fast.

When I was interviewing for jobs back in 2008, the company that hired me told me they looked at my on-line brand. I had gone through a series of interviews, included a day at the company. It was after they went and read my blog that they decided to make me an offer. This trend will continue to grow. How is your on-line brand?

One topic I’ve touched on when doing public speaking is personal branding. Back when I got my PMP certification, that was something that made me stand out. Now, it’s expected that any project manager will have that. What are you doing to make yourself stand above the crowd? Have you thought about other certifications such as ITIL or Six Sigma or Scrum Master? Having said that, don't chase after other certifications just to add letters to your name, go after those things you are passionate about. In my case, I've always been involved in process improvement, so Six Sigma made sense to me. However, I look at the new Scheduling Certification from PMI and have no interest in that. As an agile guy, the thought of building complex schedules is not something I care about.

So for this year, set a couple branding goals for yourself. Start a blog, get tweeting, write some articles for other blogs...something to show your passion for what you do.

Burning Bowl Ceremony

2010-01-04T07:09:00.002-06:00

Our church has an interesting ceremony on the first weekend of the year, the burning bowl ceremony. Everyone receives a slip of paper. On it, they write something they don’t want to carry into the new year…a bad habit, negative thought, etc. Anything that they don't want to keep doing. They put the slip of paper into a bowl that has a small fire and let it burn, so they don’t carry this new trait into the coming year.

Often people spend this time of year setting goals for what they want to accomplish…exercise more, lose weight etc. What don’t you want to do this year? Are you ready to throw that away?

Book Review - Career Renegade

2010-01-02T08:41:00.002-06:00

One of the books I received for Christmas was Career Renegade by Jonathan Fields. I'm about done with it and have really enjoyed it.

The focus of the book is on how to take something you like to do and make money at it. For example, one story in the book is about an artist that was able to find a niche market painting wineries and then selling them at the winery. The example was meant to show how even in a field that in general is hard to make money, this person was able to find a unique market.

A large part of the book focused on the on-line world. Topics like becoming a better blogger, using tools like Twitter or LinkedIn. The book has some very specific suggestions and places to go for help. Even if you aren't looking to start a new career, this book can help you improve your presence on line. I would recommend it to anyone looking for some ideas on increasing their personal brand awareness.

The Enlightened Project Manager

2009-12-22T15:06:00.001-06:00

I just finished teaching a 3 day class on agile project management to a group if PMs in Cairo, Egypt. The class was one of the outcomes of an agreement signed between the Egyptian Government and the PMI IT & Telecom SIG last year. I’m approaching 10 years of volunteer service with the SIG.

One of the points we spent a lot of time discussing is when to apply agile. I spent some time talking about the sweet spot for agile…projects that don’t have clear requirements, are not huge, have strong user involvement, and have higher risk. New technology projects are good examples.

The idea of the Enlightened PM is one that knows the right tool to use for the project they have in front of them. While there are some that would disagree, I don’t think agile is the right approach to every project. I still think there’s a place for waterfall. I also know there are projects that will work well using more radical approaches such as Kanban.

One of the discussions revolved around an SAP implementation. Our conclusion was that you could do the initial implementation of SAP using their ASAP methodology (disclosure: I helped SAP develop the project management practices that go with ASAP). However, when you start working on enhancements, you can use agile, or even Kanban to manage those changes.

One of the participants in my class was in the construction industry. While I wouldn’t recommend agile for building a house, it can be used for designing a house.

Occam's Razor

2009-12-15T23:06:00.003-06:00

I'm reading the book Plato and a Platypus Walk Into a Bar. As I was reading last night, I came across a reference to Occam's Razor. I liked their interpretation; "Theories should not be any more complex than necessary." Ockham was a 14th century Franciscan Friar and logician, razor refers to shaving away unnecessary assumptions.

I was putting some slides together this week for a workshop I'm conducting next week on Agile. One slide is an overview of Extreme Programming (XP). I'm not going to claim to be an expert on XP, but I have run projects following principles of XP. One of those principles is to use as simple of a design as you can and don't design for features you may not ever develop.

Are you making things more complicated than you need to? I was talking with one of my clients today on keeping things simple...get a basic release of the software completed and in the hands of your users and once they have a chance to use it, they'll have a much better idea of what else they need. Don't try to deliver everything at once. Or as my Dad used to say - KISS - keep it simple stupid!

Are you in debt?

2009-12-11T07:28:00.002-06:00

I read an interesting article by a colleague of mine, Scott Francis, on technical debt in BPM projects (read it here). His article got me thinking about technical debt introduced through our project management practices.

Here's an example of what I'm talking about. Let's say you're working on capturing your user stories. You've gathered a group together and had a workshop set up for the afternoon to capture as many stories as possible. Tomorrow you plan on working with your product owner to prioritize the stories. During the afternoon session, someone mentions another user that isn't present that may have some user stories to contribute.

So here's where you decide if you're going to take on some debt. You could delay your prioritization meeting and go talk to this person tomorrow or you could decide to move forward according to your plan. If you move forward, you've just accumulated the debt of having other user stories added somewhere down the road that you will have to deal with.

Now you might be thinking this is agile, change is no problem. But do you know how big that debt is? It might be something insignificant or it might require some major refactoring in order to accommodate the new story.

That's the thing about technical debt. You're making a decision now in order to move things along that will have some consequence later. Do you know how big that consequence is going to be? Just like when you're taking out a mortgage on a new house, you want to make sure you know what you're getting yourself into.

Proof that Agile Works

2009-12-04T08:26:00.003-06:00

I came across a very interesting article yesterday from Cutter Consortium (read it here). The article provided evidence about how offshoring doesn't really save you any money, but it also showed how agile does save you money.

The conclusions were based on 20 years of research across 8000 projects. It compared projects of similar size in terms of lines of code. The average project cost $3.5 million. Offshoring it reduced the cost to $3.2 million. The agile project cost $2.2 million.

From a time perspective, the on shore project took 12.6 months, 9.6 for the offshore, and 7.8 months for the agile project.

From a quality perspective, the onshore project had on average 2702 defects, an astounding 7565 defects for the offshore, and only 1372 for the agile project. So even though the offshore project cost less, you made up for it in fixing defects.

This was a pretty comprehensive study and the conclusions are pretty clear. I have been involved with offshore work, and to me that large physical gap between the user and the developer proved very challenging. Organizations I saw struggled to communicate requirements across the gap. I've always been a strong believer in close interaction between developers and users.

Not Waiting for Great

2009-12-01T20:04:00.003-06:00

Wired Magazine had an interesting article in the September issue titled The Good Enough Revolution. The article discussed how people are no longer demanding the best, but things that are good, portable, cheap options. Music was one example they used; most people prefer the low quality of MP3s over the higher quality a record can deliver because MP3s are more portable.

This is actually a theme I try to push with my clients. We could spend 9 months building an application with all the bells and whistles or 3 months delivering just the important stuff. It's much cheaper, and if you deliver faster, you realize the benefits sooner. I'll admit I don't have a 100% success rate at getting clients to see my perspective, but I'll keep trying.

Getting people to change

2009-11-25T05:48:00.003-06:00

I've been encountering a pretty common situation with some of my clients. While they seem to get what agile is about intellectually, they are still doing things the old way, seemingly unable to break their old (bad) habits.

A colleague of mine, Donna Brighton of the Brighton Leadership Group, introduced me to a new model for change, the ADKAR model, developed by Prosci.

Awareness
Desire
Knowledge
Ability
Reinforcement

So the first step is awareness. Are people aware of why they should adapt agile? Are there project failures in the organization? Do projects miss dates, fail to deliver on quality, or run over budget? How can agile solve these problems?

Next, do people have the desire to change? If they've come to accept the status quo, maybe there's no incentive to improve.

The third step is knowledge. This is where training would play a part, so people can understand the desired future state.

However, knowledge doesn't guarantee ability. Can people try the new approach without fear of punishment? Is there support in place to let them succeed?

Finally, when the desired behavior comes about, what is being done to make sure people don't fall back to their old habits?

I have always used the term Organizational Change Management (OCM) when I talk about this type of change, to distinguish it from technical change management such as scope change. I have always approached OCM from the organizational perspective; how do I get the organization to move in the new direction? What I haven't thought about much is that an organization is made of individuals, and each person will make this change journey at their own pace. My effort to change the organization must take individuals into consideration. I'll have my early adopters that can help me. I'll also have those late adopters that I have to account for. I can't assume everyone will change according to my OCM plan.

As for my clients, I think the awareness is there, so it's time to focus on the other steps to get them on the road to agility.

Afraid to Fail

2009-11-17T06:41:00.004-06:00

I am reading the book The Art of Possibility and came across an interesting section about failure. There is a story about the composer Stravinsky. When questioned about one particularly difficult section of music, he replied that he didn't expect anyone to play it, but to sound like they were trying to play it. His purpose in writing the passage was to get someone to fail when they attempted it.

Throughout our life, we are told failure is bad. However, it's through failure that we can learn. Thomas Edison didn't think his earlier attempts to invent the light bulb as failures, just steps pointing him in the right direction. Abraham Lincoln had some political setbacks before eventually becoming President of the US.

So when is it ok to fail? If you're trying a new technology, running a pilot project is a good idea. That way, if it does fail, there isn't a lot invested, and you learn something from it. If you're trying to run a 4-hour marathon and come in a few minutes slower, it could be looked at as a failure, but you still accomplished something.

We need to set stretch goals for ourselves. If we don't accomplish these goals, we've still increased our abilities and learned from them. If we always sit in our comfort zone, we never grow.

A stretch goal for me over the past few years has been to develop as a public speaker. I still get nervous anytime I stand in front of a group, but now I am much more composed. There have been presentations I've done in the past that haven't gone as well as I would have liked. I've learned the importance of spending a lot of time practicing before any presentation, even if it's just a project kick-off meeting for a small project team. If I wasn't afraid to fail, I would have never gotten to this point.

So, are you willing to fail?

Photo Credit: Ian Lewis, licensed under Creative Commons

Projects to the Point Conference - Final Wrap-up

2009-11-08T05:42:00.007-06:00

I'm home from Cairo. The P2P conference wrapped up on Thursday. I am already looking forward to the 3rd annual conference next year.

The agile track for the conference wrapped up with a panel discussion. In addition to myself, the panel included Jim Cundiff, Jesse Fewell, Dave Prior and Thushara Wijewardena (Dave and Jim pictured here during an earlier session). One of the topics we discussed was when to use agile.

I tend to look at agile as a tool, just like traditional project management tools, ITIL, Six Sigma etc. I think you have to look at your particular project and decide if this is a good project to apply the agile tool. If you're talking software development, chances are that the answer is going to be yes. I pointed out in construction, agile isn't the best approach. If you're building a bridge, you need to have all the requirements before you start construction. However, even here, you could use an agile approach to the design stage.

Dave Prior used the term "enlightened project manager" to describe someone that knows how to apply the right tool at the right time. So do you have all the tools you need in your toolkit?

Day 1 - Project to the Point

2009-11-03T10:36:00.003-06:00

I am in Cairo and the first day of the Projects to the Point conference has just wrapped up. Today featured a number of keynote speakers, including the current and immediate past chairs of PMI (Ricardo Vargas and Philip Diab), as well as H.E. Dr Ahmed Darwish, Minister of State of Administrative Development for the Egyptian government.

The Arabian Gulf Chapter of PMI recently conducted a survey into project failure. The leading cause, based on their failure, was project managers without the proper training/experience to run projects. Mr. Diab cited the young workforce in the middle east region as a factor in being able to meet the project management demands.

One of my presentations tomorrow is on knowledge management (KM), very relevant based on today's comments. A part of KM is being able to implement coaching and mentoring to share tacit knowledge among project managers. Tacit knowledge is that stuff that isn't easy to communicate, like how to run a project successfully. It requires more time commitment for experienced project managers as they need to bring their protégées up to speed as a master craftsman trains an apprentice.

Multi-tasking and Kanban

2009-10-28T21:47:00.004-05:00

I was at a presentation on Kanban put on by the local agile group tonight. I'm familiar with Kanban, but still picked up some good information.

One thing that struck a chord with me had to do with multi-tasking. In a previous blog post, I've discussed how multi-tasking doesn't work. In tonight's presentation, a statistic was shared that software developers waste 20% of their time when they are multi-tasking.

Kanban is the solution. The idea is you only take 1 task at a time and work until that task is done before you grab another one. You don't have a long backlog of work and you're not trying to manage a full plate of work with all the task switching that goes with it.

I find I'm more successful when I take this approach to work. At the beginning of the day, I figure out the tasks I need to accomplish. While I'm working on a task, I do my best to avoid interruptions. I ignore my email and avoid other distractions (or at least I try). I'll catch back up on email and other stuff when the task is done. It helps when I can keep tasks to an hour or less. If it's a big project, I break it into smaller chunks.

So if you find you are often interrupted, look at how you can break your work into small chunks and turn off the distractions while you complete your task.

Tools & Communications

2009-10-22T06:48:00.003-05:00

I had a recent discussion with one of my fellow IT & Telecom SIG board members on a budget item. There was a mis-understanding between us which stemmed from the use of an electronic poll in one of the tools we use to run the SIG. We were using a tool instead of having a conversation, which lead to mis-communications.

I've been working with a couple new clients and the tool topic has come up. My advice is always to get practices down before trying to use any tools to support your practice. One of my clients is using note cards on a white board to manage their stories, and it's working for them. They have a dedicated room for the project, most people are on sight most days, so the technique is working. Inspect and adapt can also mean continue to do things that are working well, don't change just because you can.

As for the SIG, I'm going to change the process for approval of budget items to include a conversation and not just an electronic vote. This will give people the chance to ask questions, clarify assumptions, and make a better decision. It's like user stories - a reminder to have a conversation and not a detailed requirement. Without the conversation, you're going to run into problems.

Keep it Short

2009-10-13T05:38:00.003-05:00

This past Sunday, in conjunction with the PMI North America Global Congress, I hosted a Pecha Kucha night on behalf of the IT & Telecom SIG. This served as the launch event for the new PMI Agile Community of Practice.

Pecha Kucha is a style of presentations where you have 20 slides, each lasting only 20 seconds. This was the first time that I, or the other speakers, had given this type of presentation. We all agreed it was fun, but took a lot of work to get right.

I think this brings up an important point. How often have you received a very lengthy email where you couldn't figure out the real message? Like presentations, good writing requires effort. Trying to deliver your message in a short, concise format requires you to really work on refining the message. I think people get lazy with email, throw something together, and expect you to figure it out.

One exercise I like at the start of a project is developing an elevator speech. The idea is to be able to clearly define the purpose of your project in a couple of sentences. The challenge again is to make that message clear & concise at the same time.

So next time you're sending an email, take the extra time to read it through and decide if you are getting your message across in a concise manner. If not, you need to make it shorter.

Making your problems visible

2009-09-23T06:44:00.003-05:00

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

2009-09-15T06:33:00.004-05:00

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

2009-09-04T07:44:00.003-05:00

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

2009-09-01T06:59:00.003-05:00

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

2009-08-25T07:05:00.004-05:00

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

2009-08-12T17:05:00.003-05:00

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

2009-08-06T08:55:00.002-05:00

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.

If a tree falls in the woods...

2009-07-30T09:15:00.002-05:00

I came across the Copenhagen Interpretation in a book I'm reading. This idea came about in quantum mechanics by Niels Bohr, Werner Heisenberg and others, working in Copenhagen in the early 20th century. In simple terms, the Copenhagen Interpretation says that something doesn't exist until we observe it. So if a tree falls in the woods and no one is there to hear it, it doesn't make a sound.

So what are we trying to observe on our projects? What do we try to capture by our reports, metrics, SLAs etc? The Copenhagen Interpretation supports the idea that we get what we are looking for.

I was doing work at a call center one time. There, they were looking at what percent of time the representatives were available to take calls and when they were "logged out" meaning they were taking a break, doing documentation from a previous call etc. This data point was pretty consistent across the representatives. However, when they dug a little deeper, they found a small set of people that answered significantly fewer calls. This didn't make sense since their availability was the same as others.

As it turns out, some representatives figured out how to scam the system. They watched the representatives around them getting calls and could predict when they would get a call. They logged out for a few seconds, the call went to the next representative over, and they logged back as available, knowing they wouldn't get another call sent to them for a while.

So you're going to get the behavior you look for and reward. If you reward the number of bugs the coders find, they'll find a lot of bugs. If you recognize the person that can fix the crisis, you'll get a lot of fires that need to be fought. So don't think lightly about what you measure.

Anti-Patterns in Project Management

2009-07-23T09:19:00.002-05:00

I'm on a project now working with a client on best practices for BPM projects. My focus is on the project management aspect and I have a couple co-workers focused on the software development aspects. One of the topics that came up this week was anti-patterns.

Anti-patterns can be thought of as repeating a set of actions that are anything but a best practice, or, just repeating a bad habit. It's a pretty common theme in software development. Spaghetti code is a good example, continuing to produce code that is poorly structured, confusing, or hard to follow.

But as I was thinking about it, I realized anti-patterns can apply to project management as well. I was in one organization that practiced the "death march" anti-pattern. Projects would get going, everyone would know it was going to be a disaster except senior management, and then the meltdown would happen. Then everyone gets assigned to the next project.

Another of my favorites is management by fire fighting. It's only the fires that get attention and the fire fighter working the long hours saving the day is recognized as the hero. If the organization was a little better at addressing risk, it might have a few less fires (not to mention stop rewarding people for putting the fires out if they could have prevented them in the first place).

So what anti-patterns are in your organization? Can you do something to replace them with some best practices? Are you so caught up in the day to day execution of your projects that you don't see them?

The Five S's of Lean

2009-07-17T07:26:00.003-05:00

One of the principles of Lean is known as the 5 S's. Developed in Japan, they are 5 steps that are taken to help become a more lean organization, all starting with the letter S. In English, they have been translated as Sorting, Setting in Order, Shining, Standardizing, and Sustaining. Though the concepts focus on manufacturing, they can also be applied to knowledge workers.

Sorting - What does your desk look like? Do you have piles of papers or magazines you hope to get to some day? Lots of extra cables hanging around? Business cards waiting to be put into your contact management system. The first step in becoming a lean knowledge worker is to sort your desk and office area. Keep only what you are going to need on a regular basis close by.

Setting in Order - Similar to sorting, but with more of a focus on your process flow. It's answering the question of where is the best way to arrange what I need on my desk? When I sort, my computer is something that is on my desk; when I set in order, I set up my laptop just to the left of center, with a second monitor in the center of my desk. I have a space to the right of my mousepad for documents I am working on. Setting in order becomes more important when I'm working on a client site. I have to set up every morning and need to adjust based on how much space I have. If I'm in a conference room with other people, my space may be very limited.

Shining - At the end of each day, taking a few moments to make sure your workspace is clean. Throw away that candy wrapper that's behind your monitor, sort any papers you are done with, and put books back on the shelf.

Standardize - It's important to set up standards with the people you are working with. Do you have an in-box you want anyone from your team to put papers into? Do you have a standard time for your daily stand-up meeting?
Sustain - Keeping the practice going and revisiting the other four S's when you need to. If you get a new, larger monitor, you will have to sort and straighten. If a new member joins the team, how does that change your standards within the group. Sustain is kind of like kaizen, you don't go through an improvement and stop; you keep looking for improvements.

How much technology do you need?

2009-07-14T16:09:00.003-05:00

In an interesting twist, today's stage of the Tour de France was run without race radios (article). Normally the radios are used for the team directory to communicate to the riders; things like when the next climb is, potential hazards, or where a rival is in the race. It can become important if a small group of riders break away ahead of the pack; knowing if any of those riders can take over the lead of the race and therefore need to be chased down. So it provides additional information to the riders to help decide on tactics.

The question is how do the radios impact the race? Riders seem to prefer the radios, knowing exactly what's going on. The organizers that put the radio ban in place for today thought it might add some drama. Looking at today's results, I don't think it had a big impact either way.

This got me thinking about tools to help run projects. In the workshop I ran this past weekend, I took a very manual approach; using note cards etc. I mentioned some of the tools that are available, but also said I prefer the manual approach whenever possible. If you have a team co-located, you can get away with posting your user stories as note cards on the wall and writing your burn-down chart on a white board. Things get more complicated when teams are spread across multiple locations. That's when you need to start looking into tools.

So if you're spending a lot of time keeping your tools up to date, you have to think about what value it brings. If the answer is not much, then maybe you should try going without, like the riders did today in France.

The Road to Agility Workshop

2009-07-12T21:14:00.002-05:00

Yesterday, with the help of Ron Montgomery, I co-ran a workshop on agile project management. This was a 1 day introduction to agile that was run in conjunction with the Kansas City PMI chapter. If you attended the class and are looking for the slides, click here.

The workshop went pretty well. It was tough getting everything that we wanted to cover included in a 1 day format. We received some feedback about running additional workshops that go into more detail on some topics.

What attendees seemed most interested in was how to sell agile in their organizations. What do you have to do to convince executives this is the way to go?

I think the highlight of the class was when we did a planning poker exercise. We had 50 attendees that we broke into 8 teams. Each team selected their PM and Product Owner. The remainder of the team were the "developers." After creating their user stories, each team went through the estimating process. There were some interesting discussions that followed as they tried to estimate the stories.

Proof of Concept

2009-07-07T20:07:00.002-05:00

I have a project going on now that's a proof of concept; working with a client to demonstrate how my company's software can solve their business needs.

Obviously, there are some shortcuts that I can take on this project. For one, I don't have to worry as much about testing because the application is not going to go to production. However, in good agile technique, we are testing during each iteration. At the end, we want to demonstrate a system that works, even though we may not go through all the corner cases we might in a thorough testing approach.

We also don't have to worry about documentation. We'll show the end users how to use the tool, but we don't have to worry about future users. We also don't have to worry about support documentation.

We also didn't do as much up-front work. Typically, because it is a process improvement project, we'll look at the as-is process and figure out the ideal to-be process to implement, then start development based on improvements we've uncovered. In this case, we are just re-implementing the as-is process with the only improvements being what comes with our software; things like improved efficiency, better reporting, better tracking of resources and workloads among other things.

So a proof of concept should be just a first step. Assuming we are successful, we will be able to come in and really help our client. So while the demands on this project aren't as big as a full blown implementation, we still need to show business value. On any project, that's really what it comes down to.

Drinking from a fire hydrant

2009-06-25T11:49:00.001-05:00

So I started a new project this week and am in the middle of figuring everything out. I am reminded of when I was starting nuclear power school with the Navy and was told the training was like drinking from a fire hydrant, a lot would be coming out and it was my job to catch as much as I could.

I’m working with a company in financial services, so it isn’t completely alien, but I am finding there is a lot of terminology I am trying to pick up. Add to that the aspect of meeting new people, learning their roles, and how the organization functions. Then there’s the specific aspects of the process that is the subject of the process improvement/BPM project. There are a lot of moving parts.

So how does someone jump into a project and “hit the ground running?” There are a couple of things I’ve learned along the way. The first thing is to get your hands on any documentation and read it. I find that I read everything once, and then go back a couple days later after I have a bit more context and read it again.

Next, ask questions. With a little bit of context, you can ask questions that make it sound like you aren’t completely clueless. I’m usually quiet for the first day or two as I gather that context so I can ask better questions. The questions you ask say a lot about you, or as a t-shirt my daughter has says, “There are no stupid questions, just a lot of inquisitive idiots.”

Finally, you need to relate what you’re doing to what you’ve done before. During some of my conversations with my client in the last day I was able to do this. I could relate some specific requirements they have to what I’ve delivered in past projects. This is when, as a consultant, you show that your experience is worth the money they are paying you to be there.

Sunk Costs

2009-06-19T18:39:00.002-05:00

Are you a good decision maker? Do you consider the facts? Explore the options? Look at the big picture are well as the details?

How do sunk costs play into your decisions. If you've invested a lot of time and money into a project, does that influence your decision on whether or not you should kill the project?

Sunk costs is what has already gone into a project that you can't recover. At one telecommunications company I worked for, sunk cost played into decisions. They didn't want to kill a project that they've already spent so much on.

Sunk costs should not influence your decision. You need to look at the current situation and decide if the investment from today forward will result in the benefits you are aiming for. It doesn't matter if you've already dropped $2 million on a project, what matters is what it will take to complete the project and what your benefits will be. What this can mean is that if you are behind on schedule, over budget, and it's going to take a lot more to finish the project, then maybe you need to kill it even if you already spent a bunch of money.

Disconnecting

2009-06-16T11:57:00.002-05:00

If you've been following my blog, you'll notice I haven't made a post in over a week. I just got back from a week cruise to Alaska. During the cruise, I was completely cut off from the rest of the world. I wasn't looking at the paper, wasn't checking email, or even using my Blackberry. Now that I'm back, I realize the world didn't stop without me.

It was good to get away, not only from work but really from everything including volunteer work, writing, chores around the house etc. The only regular activity I kept up was working out. Instead, I was taking a lot of pictures, getting to know Aperture better, and enjoying nice meals with my family. Now I feel re-charged and ready to get back into the projects I have going on.