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.