seven deadly habits of dysfunctional software managers

BW1 Concurrent Session 11/7/2012 10:15 AM

"Seven Deadly Habits of Dysfunctional Software Managers"

Presented by:

Ken Whitaker Leading Software Maniacs

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Ken Whitaker Leading Software Maniacs™ (LSM)

Ken Whitaker of Leading Software Maniacs™ (LSM) has more than twenty-five years of software development executive leadership and training experience in a variety of technology roles and industries. Ken has led commercial software teams at Software Publishing, Data General, embedded systems software companies, and enterprise software suppliers. He is an active PMI® member, Project Management Professional (PMP)® certified, and a Certified ScrumMaster (CSM). Sources for LSM’s presentations come from case studies, personal leadership experience, the PMI Project Management Book of Knowledge (PMBOK® Guide), and Ken’s leadership books: Managing Software Maniacs, Principles of Software Development Leadership, and I’m Not God, I’m Just a Project Manager. Read more at pmchalkboard.com and pmuniversity.com.

7 Deadly Habits of Dysfunctional Software Managers

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


Ken Whitaker

Copyright © Leading So2ware 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



My goal today?

You’ll learn at least one new tip today

to put into practice today!



Agenda

§  Releasing a Product Before It is Ready §  Hiring Someone Who is Not Quite Qualified, But

Who Everyone Likes §  Make Every Decision a Consensus Decision §  Promising Developers Incentives §  Delegating Absolute Control to a Project

Manager §  Taking Too Long to Negotiate Feature Sets and

Schedules §  Ignoring a Process In Order to Release Quickly


Releasing a Product Before It is Ready


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





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)



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





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



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





Process Groups

Implementation Initiating Planning Execution Monitoring &

Controlling Closing

Plan Quality Perform Quality Assurance

Perform Quality Control

Quality Management knowledge area … in the PMBOK® Guide provides great advice

Project Management InsAtute, a Guide to the Project Management Body of Knowledge, (PMBOK® Guide) -‐ Fourth EdiAon, Project Management InsAtute, Inc., 2008, extract from Table 3-‐1, Page 43

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





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)



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





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!





Process Groups


Controlling Closing

Develop Human Resource Plan

Acquire Project Team

Develop Project Team

Manage Project Team

Human Resource Management knowledge area … in the PMBOK® Guide provides great advice


Make Every Decision a Consensus Decision


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





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!




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) §  Loss of confidence in management §  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





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



Process Groups


Controlling Closing

Develop Project Charter

Develop Project Management Plan

Direct and Manage Project Execution

Monitor and Control Project Work

Close Project or Phase

Perform Integrated Change Control

Project Integration Management knowledge area … in the PMBOK® Guide provides great advice






Process Groups


Controlling Closing

Identify Stakeholders

Plan Communications

Distribute Information

Report Performance

Manage Stakeholder ExpectaAons

Project Communications Management knowledge area … in the PMBOK® Guide provides great advice


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



“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?




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





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



Best practice

Awards are significantly better than

incentives





Process Groups


Controlling Closing

Develop Human Resource Plan

Acquire Project Team

Develop Project Team

Manage Project Team

Human Resource Management knowledge area … in the PMBOK® Guide provides great advice


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?



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

§  Low team morale §  No confidence in management §  No trust with decision making process

§  If not handled correctly… §  PM role became a “scheduler”





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!



Process Groups


Controlling Closing

Collect Requirements

Verify Scope

Define Scope Control Scope

Create WBS

Project Scope Management knowledge area … in the PMBOK® Guide provides great advice




Taking Too Long to Negotiate Feature Sets and Schedules


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

Nobody wins (but I do have

a little secret…)



§  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!





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?”




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





Process Groups


Controlling Closing

Collect Requirements

Verify Scope

Define Scope Control Scope

Create WBS

Project Scope Management knowledge area … in the PMBOK® Guide provides great advice


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!”



The result is always a mess

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???



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 action of an “out of control project” took place:

You guessed it: Project restart!

CHAOS 2000 survey results (The Standish Group)





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.”



Process Groups


Controlling Closing

Develop Project Charter

Develop Project Management Plan

Direct and Manage Project Execution

Monitor and Control Project Work

Close Project or Phase

Integration Management knowledge area … in the PMBOK® Guide provides great advice




Bibliography

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

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

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






Soooo, did you learn what you expected

today?

www.leadingswmaniacs.com
