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.