Previous month:
December 2009
Next month:
February 2010

Are Your Metrics Dumb or Smart?

Agile Estimates On February the 16th I will be presenting at the Calgary Software Quality Discussion Group. This was the first group I presented for when I moved to Calgary nearly 10 years ago and I am very happy to go back and talk about a topic I really care about: Project Metrics. I care not in the sense that I think they are fantastic, instead I care because I think the majority of common metrics are counter productive and misguided. Here’s the outline:

Lessons Learned in Project Metrics - Are Your Metrics Dumb or Smart?


Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".

Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.

More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. In the real world, rear-view mirrors are much smaller than windshields for good reason, yet the accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.

In this presentation I will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.
 

Registration Link

Building Trust and Respect

Agile I have just started my second season of mentoring for our local PMI chapter. This week’s launch workshop was facilitated by Right Management and they introduced a great model for building (and rebuilding) Trust and Respect that I would like to share. It was used to help explain how to build trust and respect with those we are mentoring, but it is a useful model that has much wider applications.

Establishing trust and respect can build tremendous support for goals, and likewise losing trust and respect puts us back at the beginning in a relationship or even further behind and the process has to start again. I am sure we have all experienced it, I know I have. Trust is a slow process to build and can be quickly eroded by a single bad deed or poor choice, as shown in the graph below.

Trust and Respect Lifecyle
 

While this is common sense stuff, what I liked about the workshop is the Howard Jackson Model for systematically building trust and respect. It is a repeatable series of steps that build on from each other in sequence to establish better collaboration.
 
Respect Pyramid
 
In this model we start at the bottom of the pyramid with Straight Talk, and move through the steps of Listening for Understanding, Making Commitments, being Reliable, creating Trust, and then finally earning Respect.

Straight Talk

Straight Talk  - Open and direct communication is the first building block for trust and respect.

Listen
Listening for Understanding – Focus your attention on understanding the meaning behind what people are saying. There is a big difference between waiting for your turn to speak and really listening. Hear, Understand, Interpret, and then Respond.

Make Commitments
Making Commitments – Be clear about what you will do. Agree on the What, By When, By Whom, and How steps. Communicate your intentions and stick to them.

Reliability
Reliability – Do what you say you will do without fail. If circumstances have changed and it no longer makes sense to do what you said you would do, communicate back and explain why, and discuss and agree on the new steps.  Follow through over-and-over, be reliable, unfailing, dependable.

Trust
Trust – Trust results from the firm belief that another person can be relied upon. Trust is the result of straight talk, making sure you understand and are understood, and keeping confidences as well as commitments.

Respect
Respect – Although there are many levels of respect, the respect that follows trust leads to deep esteem for another person. We value their thoughts and input, and we know we can count on them because they have proven themselves out to us.

Why so much focus on soft skills for an Agile PM Blog?
When I started this blog in 2006 I wanted to explain the new techniques used on agile projects in an easy to understand format, with real life examples. Now I find myself writing more on soft skills than agile techniques.

This is because people are the engine that drives a high performance project. Without a good team that embodies trust and respect, the best process and tools in the world will not help you. I am as geeky about process as the next agilist, I love experimenting with Kanban and Lean and know that they offer better ways of executing projects. However, bigger improvements can be had from the people side of things.

Another passion of mine is mountain biking. I lust after lightweight exotic bikes like the Super Fly 100 and S-Works Epic, imagining how much faster I could go, the hills I could finally climb. I am sure they would help, but the advantages are small, a good rider will dwarf the performance gains of the machinery and it comes down to the person powering the bike not the bike its self. It is like this with people and process too. Yes we can tweak and improve the process and I encourage you to, but the biggest gains come from within the team. From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes. We undoubtedly need a combination of soft skills, tools, and process, but when considering where to focus effort I believe the biggest payback is on the people side.

"From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes."

PMI Agile Survey

Survey It is time to tell the PMI what Agile project management resources they should be developing. Please take a moment to answer this 7 question survey and help direct the PMI in 2010.

In 2009, the PMI Agile Community of Practice was launched to “equip PMI members with agile skills and knowledge”. To accomplish that goal, several services were offered to project managers of all walks interested in agile project management. All responses are anonymous, and all results will be publicly distributed.

PMI Agile Survey


Six Project Trends Every PM Should be Aware Of

Future As we start 2010, the second decade of the 21st century, project managers really should be embracing 21st century technologies and approaches. While developers and other project members have been benefiting from improved communication and collaboration via new technology in the last 10 years, project managers have been slower to adopt them.

The plus side of being a late adopter is that most of the kinks get ironed out before you experience them and all the features you may need have probably already been developed. So, time to get with it. Perhaps it can be a New Year’s resolution to at least examine these tools and approaches if you are not already using them on your projects.

The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.

Also, project management is a largely individual activity, teams of developers and business analysts are far more common than teams of project managers, so peer-to-peer learning and tool support is almost nonexistent for project managers. Plus, project management can often be a reputation based market and to some people fumbling around as a beginner in a new approach is very uncomfortable to them. Well it is time to get over it, this is how we learn anything, and if you are concerned about looking foolish, just imagine how foolish you will look when everyone else has moved with recent trends and you are in the last stand of dinosaurs.

Continue reading "Six Project Trends Every PM Should be Aware Of" »