Posted by: drmiw | February 24, 2015

Why it doesn’t pay for project managers to be agile with the truth

Recently I met with an organisation who have a familiar problem: Their software developers can’t keep up with their agile product backlog and their customers are getting frustrated. There are ways to improve such a situation on the management side, but the most important thing in any project is honesty.

Improving agile project management

In my meeting with the aforementioned organisation’s programme management team I suggested a number of ways to solve their particular problems, including:

  1. cutting through the management layers to improve communications and ensure that business value is captured in accurately prioritised user stories;
  2. ensuring their developers are not distracted by trivial support issues when they are trying to code; and
  3. coaching the software team so that they speak up more and work better together.

They were very open to ideas and there was a willingness to shake up their Prince 2 aligned project management structure to make it more agile and less document driven. And my specific suggestions for modifying their issue escalation processes to reduce the frequency of the ‘tap on the shoulder’ from non-techies that developers dread, were well received. However, with regard to my third point (see above), they expressed a belief that some developers will always prefer to be told what to do rather than take initiative on projects and suggest solutions. I disagreed and said that with a bit of coaching and the right agile environment, any developer should become a real contributor.

They also expressed a preference for project managers to not to be too technical, while I contended that, all other things being equal, technical expertise should be a positive trait for a project manager – a help not a hindrance. So could their apparent lack of faith in technical people be the root of their backlog problem and their customers’ frustration?

Honesty is the best agile policy

Naming no names, I discussed the points raised above with an associate of mine who currently works in a multinational IT services company, and he said to me that in his experience “the less technical the manager, the worse they are at delivering projects”. He gave an example of a project he is currently working on one in which the last 5 sprints were estimated at 70 story points but actually took 120. He said there was a reluctance to use historical evidence to correct the points estimate for the next sprint and that the project managers had effectively been “lying to the client”.

According to my associate, a big failing of his employer’s non-technical project managers has been the badgering of developers into shorter estimates. He referred me to the following quote from a classic article on Evidence Based Scheduling:

Don’t let managers badger developers into shorter estimates. Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.

Joel Spolsky

A very senior and very technical manager who “doesn’t tolerate” badgering has now been charged with rescuing this failing and consistently underestimated project. My associate says “the client appreciates the honesty above all else” and “it’s a pity some of the non-technical management team don’t”.

Do techies make the best project managers?

In this post I’ve provided anecdotal evidence that software project managers are more likely to succeed if they have substantial technical expertise, but as a bit of a techie myself I may be biased and you’ll find plenty of articles arguing the opposite. I’ve worked with some fantastic non-technical project managers who respect and trust the developers they work with and grasp the technological ideas and business issues well enough to ensure success. So is technical understanding rather than technical expertise all that is required for an honest and capable agile project manager to succeed on complex software projects? I’d be interested to see this question answered by a proper study, if it hasn’t already.

In any case, techies are often rightly or wrongly perceived to have little business acumen so their involvement in software projects may be limited to following instructions, which is not the agile way; and if developers are more involved in trawling for user stories and estimating their own time, without being badgered by project managers, then honesty will prevail and projects will be less likely to fail.

Dilbert cartoon showing a project manager insisting that a developer reduces his estimate from 3 days to 2

Advertisements

Responses

  1. “Honesty is the best agile policy” – so true! thank you for the great post. As for the tight deadlines project managers give to the developers – sometimes PMs say, that “otherwise these developer’s shouldn’t work hard at all”! I saw so many exhausted, not motivated and “always late” teams which were managed by such PMs.
    Been techy myself I think PMs should have tech background, as it makes things easier. Of course, I am not an expert in all programming languages from my projects, but I completely understand the challenge.
    Some time ago I found myself taking part in the project as the “customer” and was working with such kind of “lying” manager. It is so hard! I understand why clients think honesty to be the most important thing) Even the speed is not crucial if you are predictable.
    Seems that this “lying” and “been too optimistic” is a part of PMs culture? Like a rule for their professional guild? 🙂

    • Thanks, tisquiiirrel. I think human nature and false optimism are to blame for some project managers telling their customers what they think want to hear, but with honesty and evidence based scheduling they can avoid that problem.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: