More on Culture

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

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

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

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

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

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

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.

Got a story to tell?

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

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

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?

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?

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

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

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

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

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

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

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;

1. Learn the rules
2. Practice the rules
3. 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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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.