PMI Central Iowa PDD

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

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

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

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

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

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

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.