And here is part 2:

Recently, I started to get very interested in Kanban and have spent some time researching the topic since it is something I have not yet used in practice.  Shortly, I came across this excellent series by Pawel on his struggles and process of implementing Kanban with his team.

Then, I came across this video of Pawel presenting on the topic and just had to share it with you here.

Pawel, thank you so much for your contributions, this is really great stuff!!!

Doing it twice in a few months makes you reflect on lessons learned.

There are a whole new set of stakeholders, and whole  new team.  Every individual has their own history, contributions, and incentives in relation to the project at hand.

I have said for a  long time that the primary quality I respect in other project managers and try to develop in myself is empathy.  My lessons learned of late are in accordance with this insight.  Empathy is really about trying to fully understand where your stakeholders are coming from as human beings as well, not merely their “role” on the project.

Team Empathy

Some rights reserved by Patrick Hoesly

You may discover that Joe has experience with a type of work that Matt is doing, and Matt is really struggling with it.  Joe was never asked and never volunteered this information, but now that you’ve spoken with him on a human level you understand this and can make positive changes as a result.

Customer Empathy

Whether it is one individual representative or a myriad of end users and managers, understanding how they feel about various aspects of the project is critical.  Requirements can be interpreted many ways without this context, and there are usually design preferences that it will benefit you to understand.

In a complex project environment, you may have multiple key stakeholders as customers and their expectations from you as the project manager will vary widely.  Some may expect meticulous reporting, some may not care.  Preferred communication methods and styles vary from person to person.  The list goes on and on.

Sponsor Empathy

Your sponsor will also be coming at this project with a unique set of goals for you and the project itself.  If you have a relatively “hands off” sponsor they may give you lots of room to breathe.  On the flip side, there can be a striking lack of autonomy or just  a big chunk of your time taken up by a sponsor who wants to be constantly informed of every little detail or has you running on wild goose chases all the time.

It’s important to know where your stakeholders are coming from very early on so you can be proactive.

Build trust early by:

• Showing sincere interest in their perspective
• Help them understand your perspective
• Taking action to accommodate their interests and assuage their fears

I sat down and read Anchoring and Adjustment in Software Estimation and it was well worth my time.

by Andrew Stawarz via Flickr

To cut to the chase, the subjects were tasked to give estimates for software tasks in a controlled manner, in 3 groups with various “anchoring” methods being used.  The only difference between the groups was the expectation statement by the manager before estimation.

Group 1 (control – no explicit anchor given)

“I’d like to give an estimate for this project myself, but I admit I have no
experience estimating. We’ll wait for your calculations for an estimate.”

Group 2 ( ’2 months’ condition)

“I admit I have no experience with software projects, but I guess this
will take about 2 months to finish. I may be wrong of course, we’ll
wait for your calculations for a better estimate.”

Group 3 (’20 months’ condition)

“I admit I have no experience with software projects, but I guess this
will take about 20 months to finish. I may be wrong of course, we’ll
wait for your calculations for a better estimate.”

You will need to read the full paper to see all the goodies (and to determine if you think it is relevant to your domain), but I would like to summarize some of the results I found striking.

These were the results among all participants, and there are other slices of the data available in the paper including only experienced participants and also by estimation method chosen.

’2 months’ condition

• mean – 6.8 months
• median – 6 months
• standard deviation – 3.7

control – no explicit anchoring

• mean – 8.3
• median – 7
• standard deviation – 4.4

’20 month’ condition

• mean – 17.4
• median – 16
• standard deviation – 5.6

The results in general coincide with my own experience on this matter.  An important point to note is that even though they were supposedly estimating the exact same software requirements, it is very likely that the ’2 month’ group would have produced a significantly different product than the ’20 month’ group.

Food for thought.

When you and your team are putting together estimates, what influences are creating these anchors?  From my experience there are many of them, some of which are likely to be arbitrary or set (even inadvertently) without sufficient knowledge or experience.  They may be coming from stakeholders, sponsors, the project manager, or even a team member/lead.

My favorite example of this is when a team is asked to provide a “back of the envelope” estimate without really understanding the scope yet.  It produces a bad estimate and sets a rather arbitrary anchor for future estimates.

What do you think?

• GAO Cost Estimating and Assessment Guide
• 2008 NASA Cost Estimating Handbook
• Why 3 Point Estimates Create False Optimism
• Estimating Effort: Part 3