Is the Grass Greener on the Other Side of the Fence?

[article]

Lessons Learned #2-#4

  • Present solutions, not problems when faced with PSI
  • The solutions should be actual experiments or pilots with data
  • Have the development team members present the results. They did the work; let them explain it. The results will have greater credibility

Which Way Is the Wind Blowing?
Occasionally you will run into a manager who seems to have lost his compass. He will do whatever he is told by his boss, ignoring past experience that would tell him to at least protest mildly at the direction given.

I was approached by several development team members who complained they were being told to remove code inspections from the project plan because there "wasn't enough time to inspect all the code." It was interesting that years before, this manager was an early adopter of inspections, albeit at the direction of his boss. She was one of the rare "initiates change" managers at the far right side of the curve. His current boss was unconvinced of the value of inspections in the development environment, and saw no reason to "waste" time and delay the start of testing. (One might ask, if you do not need to inspect, then you do not need to test either, but then the senior PHMs might accept that proposal!)

What we proposed was to inspect a sample of the total code, and base the decision on whether or not to continue inspections on the results of the sampling. We had good numbers on the cost of defects found in test, so it would be a straightforward data analysis to determine whether or not to continue. The conditions to which we agreed were:

  1. The code samples would be a representative sample based on complexity
  2. The team would faithfully adhere to recommended preparation and inspection rates
  3. The team would collect the data accurately, because this was another very complex product, it wasn't surprising that the defect rate for the inspected code justified continuing inspections

To say we fooled the manager might be a little strong, but we were reasonably certain of the outcome and the team members were motivated to do their best to justify their positions. Keep in mind, this was not a scientific experiment, but an experiment to justify continuing a process (i.e., participants were not unbiased).

Lesson Learned #5

  • In the face of resistance, propose a low-cost experiment (such as sampling) to evaluate use of the proposed process or idea. It does not necessarily have to be a fair experiment either. (Accurate, yes, but it doesn't have to be fair. Think of it as gambling when you are the only one who knows the outcome is a certainty.)

In each of these examples, understanding what makes your boss tick is critical to getting your way. Giving up, calling him an idiot, or assuming he would not recognize a good idea if it hit him between the eyes are all forms of transferring the blame to someone else. Remember that when you are proposing a change or new way of doing something, you bear the responsibility for selling that idea to the decision makers. To do this effectively, you need to understand what they react to or are paid to do. Once you understand that, it is a lot easier to get your way.

About the author

Ed Weller's picture Ed Weller

Ed Weller is an SEI certified High Maturity Appraiser for CMMI® appraisals, with nearly forty years of experience in hardware and software engineering. Ed is the principal of Integrated Productivity Solutions, a consulting firm that is focused on providing solutions to companies seeking to improve their development productivity. Ed is a regular columnist on StickyMinds.com and can be contacted at edwardfwelleriii@msn.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03