Seven Deadly Habits of Ineffective Software Managers

KN-7DH

Copyright © 2009-2014 Leading Software Maniacs, LLC. All Rights Reserved. 1

7 Deadly Habits of Ineffective Software Managers

Ken Whitaker

Copyright © 2009-‐2014 Leading So8ware Maniacs, LLC. All Rights Reserved.


Leading Software Maniacs Marks Applying Project Management Principles to Software Development Leadership,

Principles of Software Development Leadership, 4Ps, Leading Software Maniacs, Soft-Audit, Jus’ E’Nuff, Nerd Herd Game, the 4Ps logo, the Leading Software Maniacs logo, PM University, PM Chalkboard, and the Nerd Herd

Game logo are marks of Leading Software Maniacs, LLC.

Project Management Institute Marks PMI, PMP, PMBOK, the PMI logo, and the PMI Registered Education Provider

logo are registered marks of the Project Management Institute, Inc.

Agenda

§  Everyone should refer to your “7 Deadly Habits of Ineffective Software Managers” comix

§  For the next hour we’ll discuss each of the 7 deadly habits … … and constructive ways to handle them


KN-7DH



My goal today?

You’ll learn at least one new tip today

to put into practice today!


Agenda

Releasing a Product Too Soon Hiring Someone Who is Not Quite

Qualified Rely on Consensus Decision Making Promising Developers Incentives

Delegating Absolute Control to a Project

Manager

Taking Too Long to Negotiate Feature

Sets Ignoring a Process for a Quick Release

1 2 3 4 5 6 7

Releasing a Product Before It is Ready


Ø Habit 1 §  Habit 2 §  Habit 3 §  Habit 4 §  Habit 5 §  Habit 6 §  Habit 7

KN-7DH




Daniel, newly promoted software executive, wants to prove himself

§  Company was in trouble §  3 quarters of disappointing financial results §  A major product upgrade in progress §  …and it needs to be released this quarter

$0 $100 $200 $300 $400 $500 $600 $700

Q1 Q2 Q3

Q4 (current)

Company Quarterly Financials

Planned

Actual



Daniel thought the delivery was possible and proclaimed:

“We CAN deliver the software suite THIS QUARTER!”

Then, Daniel informed his team of the news…



“This software isn’t close to being ready for release!”

“Get with it, Man … NO software is 100% error free!”

Becky, Engineering Lead, wearing a “Born to Kill Microsoft” helmet

Dante, QA Lead (a descendant from Dante’s Inferno)

KN-7DH




0

1

2

3

4

5

6

7

8

9

10

M T W T F M T W T F

Def

ects

Daily Progress

Defect Tracking Control Chart

Incoming

Corrected

A month went by §  Defect trends (incoming versus fixed) not good §  Daniel presented facts back to the executives

“No quarter shipment is possible”

§  What did the executive team decide???



The executive team made the decision to:

1. Release the product anyway

2.  We’ll follow with a quick maintenance update

“You can always show how

customer-centric you are by how fast to market you release and how fast you fix the defects”

Crazy-talkin’ VP of Marketing told the executive staff



Deadly Results §  Product launch was a disaster! §  Management team had no recourse but to layoff

staff §  Engineers worked hard to correct issues…

and to help customer support §  Company lost credibility with customers §  Management team lost credibility with

employees §  Everyone paid the price for poor quality

KN-7DH




What could have been done differently? 1.  Never commit until you have the facts and

support from the team 2.  Rather than be a hero, ensure that risks are

understood and communicated frequently

There’s one more monster

thing...



0

1

2

3

4

5

6

7

8

M T W T F M T W T F

Def

ects

Daily Progress

Defect Tracking Control Chart

Incoming

Corrected

What could have been done differently? 3.  Always make decisions on your predefined

checks and balances

Hiring Someone Who is Not Quite Qualified, But Who Everyone Likes


§  Habit 1 Ø Habit 2 §  Habit 3 §  Habit 4 §  Habit 5 §  Habit 6 §  Habit 7

KN-7DH




Shelly wants to hire a senior database engineer

§ Required skill set 1.  Designer and implementer (“hands on”) 2.  Balance mixed workload (multitasking) 3.  Ability to communicate 4.  Demonstrated experience in C#, Java, …

or is it just desired?



Position was posted §  Received tons of résumés

(out of a 100, how many are usually qualified?) Interviewing took place, no great candidates §  Three months came and went … §  In walks Brian! §  Interviewed well, articulate, employed, … §  Has been technical, recently a project manager



Brian comes in for a second round Shelly whispered the “low down” before the interview §  Interview feedback was mixed, isn’t it usually? §  Wasn’t quite as technical as the team would like §  Would fit into culture quite well §  Genuine excitement for the candidate §  HR performed reference checks

(Shelly didn’t have the time)

KN-7DH




Bottom line:

Brian was hired. Great!



At first everything went well… 1.  Then Brian started getting behind 2.  Team had to shoulder his workload 3.  Resentment set in 4.  After three months…

Brian was let go!



Deadly Results §  Set the project back §  Destroyed team morale §  Undermined confidence in hiring manager/

process §  Brian’s résumé now has a major blemish

KN-7DH




What could have been done differently?

1.  Solidify job expectations as requirements 2.  Pre-screen with targeted job posting

3.  Shelly should have performed reference checks



Best practice You could resort to the try before you buy approach, right?

No!

… this usually means there’s no confidence in the hiring process

Make Every Decision a Consensus Decision


§  Habit 1 §  Habit 2 Ø Habit 3 §  Habit 4 §  Habit 5 §  Habit 6 §  Habit 7

KN-7DH




Prior project was just released §  Major product update badly needed §  Tim, project manager, kicks off a

team meeting: “Let’s decide what goes into the next version!”

§ No agenda, just ideas…

This meeting ended BADLY!!!



A second try… Tim was better prepared with multiple lists: §  Key defects §  Customer feature requests §  Customer support issues §  Competitor’s key features

And, everybody was invited!


This time, there was lots of brainstorming: §  War room formed §  Each department had a different priority view §  Needs of the customer, quality, revenue resulted

in an impasse §  Jody, at the mercy of an indecisive jury, stormed

out!

I guess consensus didn’t work this time!!!


KN-7DH




What do you think happened? …The executive team stepped in and took control! 1.  “The business was in pain, no more

procrastination: we’ll decide for you!” 2.  “Those features that will bring in the most

revenue win.” 3.  “Case closed!!!”



Deadly Results §  Nobody wanted to go through this again §  Team’s morale wasn’t good on new project

(features were decided for them) §  Wasted time and energy §  What if the forced decision was wrong???




1.  Prepare agendas and desired outcomes (Tim didn’t)

2.  Establish a unified decision criteria at the beginning of a project

3.  Add credibility and sense of urgency with time boxed meetings

you don’t have to invite

everybody either!

KN-7DH




Best practice 1.  Agree to the right decision criteria up front 2.  Involve the right stakeholders 3.  Prepare! do the necessary homework 4.  Buy-in is more important than consensus 5.  Clearly communicate and reinforce the final

decisions

Promising Developers Incentives


§  Habit 1 §  Habit 2 §  Habit 3 Ø Habit 4 §  Habit 5 §  Habit 6 §  Habit 7

. . .



§  Habit 1 §  Habit 2 §  Habit 3 Ø Habit 4 §  Habit 5 §  Habit 6 §  Habit 7

KN-7DH




“Let’s motivate the programmers by dangling some incentives!” §  Jason reluctantly offered incentives to two of the

key engineers One engineer wasn’t convinced, but reluctantly agreed

The other engineer was excited, “Why not? I could use the money!”


The “catch”!

A delivery schedule must be made So, did the team deliver?

Oh oh – what did management do?

And then what happened to

the incentives?




Deadly Results

§  You guessed it! The incentives were dropped §  Incentivized members were mad §  Non-incentivized members

found out, then they were mad §  Management lost all

credibility

KN-7DH




What could have been done differently? 1.  Management vs employee culture statement:

Win-win, win-lose, lose-win, or lose-lose 2.  Avoid encouraging incentives: they can

introduce shortcuts and bad implementation 3.  Always reinforce the right culture:

Team-centric Commitment

Trust Transparency



So what happened to the project? Glad you asked… 1.  Project was FINALLY

released! 2.  The best

developers quit out of disgust

3.  The company eventually folded



§  Definition

Two definition terms stand out for Incentive:

inducement and

bait

Merriam-Webster's Dictionary and Thesaurus

KN-7DH




Best practice

Awards are significantly better than

incentives

Delegating Absolute Control to a Project Manager


§  Habit 1 §  Habit 2 §  Habit 3 §  Habit 4 Ø Habit 5 §  Habit 6 §  Habit 7

There is typically a division of power



where a balance of power is needed instead

The team

Is command & control

needed?

KN-7DH




Question

Just how technical does a project manager need to be?



Lana chosen by Rowland 1.  “Rollback” logic

feature needed 2.  Lana presents the

story to the team 3.  The team commits to

2 weeks of effort

Rowland gets involved with Lana 1.  “Rollback” logic re-

explanation 2.  May need a more

robust solution 3.  The team commits to

2 months of effort WHAT HAPPENED?



Deadly Results §  Negative impact to the team §  If not handled correctly…

… the PM role became a “scheduler” … and that ain’t good!

KN-7DH




What could have been done differently? 1.  W-W-W-W

2.  If you don’t know the content, buddy-up with somebody who does!

Taking Too Long to Negotiate Feature Sets and Schedules


§  Habit 1 §  Habit 2 §  Habit 3 §  Habit 4 §  Habit 5 Ø Habit 6 §  Habit 7



§  Project was shipped §  The team was exhausted §  Project manager and

product manager met Then they met with with the team… “What do you want?” “Ohhhhhh sure, we’ll get back to you!”

EVERYTHING!

KN-7DH




Team responds with laundry list estimates “Too many and unfocused, we’ll get back to you”

Product management is thinking “I don’t trust these estimates…”



The one thing both parties didn’t realize…

§  Over 50% of requested features aren’t even used!

Jim Johnson, XP 2002 requested feature survey results (The Standish Group)

Always7%

Often13%

Sometimes16%

Rarely19%

Never45%

Could this be an

example of the 80/20 rule?



Deadly Results §  After weeks of negotiating it came down to this:

“What’s more important: the schedule or the feature?”

“BOTH!”

§  Two sides to every coin: “I lost a lot!” & “Why weren’t you all realistic to begin with?”

KN-7DH





1.  Reduced unnecessary gaps between projects

2.  Establish a Project Vision first 3.  Use forward motion technique

4. Minimize any clash between departments

and emphasize trust

Ignoring a Process In Order to Release Quickly


§  Habit 1 §  Habit 2 §  Habit 3 §  Habit 4 §  Habit 5 §  Habit 6 Ø Habit 7

“We gotta get this product released!”



Sigh…this isn’t going to end

well!

My friend’s company has no process at all…

They seem to ship on time!

We don’t…too much process

Isn’t that what agile is

about???

KN-7DH




Self-driven team empowered to just “get it done” At first… “This is pretty neat” “No meetings – we can focus on doing the work”

E-mail becomes The communications vehicle



Deadly Results

Project status becomes difficult to determine

Water cooler decisions abound

Engineers become feature happy

Quality is DOA (not everybody is kept informed)

“Gold plating” suits me mighty fine!



The #1 outcome of an “out of control project” took place:

You guessed it: Project restart!

CHAOS 2000 survey results (The Standish Group)

KN-7DH




A not-so-famous marketing consultant told me

“Any software development team can get by without a process once

… but you’ll always get beaten by a competitor

with a process in the long run.”

Bibliography

§  Project Management Institute, Inc. A Guide to the Project Management Body of Knowledge: PMBOK® Guide, 5th Edition. Newton Square, PA: Project Management Institute, 2013.

§  The Standish Group. Chaos Reports (1994-2006). www.standishgroup.com.

§  Whitaker, Ken. Managing Software Maniacs: Finding, Rewarding, and Motivating Software Developers. New York: J. Wiley & Sons, 1995.

§  Whitaker, Ken. Principles of Software Development Leadership: Applying Project Management Principles to Agile Software Development. Boston: Course Technology PTR, 2009.



KN-7DH



www.leadingswmaniacs.com


Seven Deadly Habits of Ineffective Software Managers

Software

Transcript of Seven Deadly Habits of Ineffective Software Managers