Scaling Agility

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

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

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

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

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

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

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

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

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;

1. Understand the problem
2. Design the solution
3. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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?