Share via

There are no right answers.

  • Article

All troubled projects share one and only one characteristic.  Things have gone wrong.  Terribly wrong.  Other than that, everything is, and I contend must be, unique.  Let's face facts here; projects are the accumulated work of people. No amount of consistent process can ensure individuals with unique personalities, under unique conditions, will do the same things, the same way nor will they have the same results.

Consider the common practice of buying new tools to improve the team’s velocity thru Automation.  New tools are frequently added to a project to automate repetitive, labor intense tasks like regression testing.  Some testing tools can reduce days of potentially error prone human testing to hours of precise, repeatable tests.  Seems simple enough. Tool based automated testing is good and will improve both product quality and team velocity.  Unfortunately this is not always true.

Troubled projects seem to have a very high likelihood of poor test practices. While many may actually be suffering from a complete lack of test all together, all too often they are mired in the "solution" tool based automation has become.  These teams didn't have experience with test before bringing a tool to the party.  The tools positive value is overcome by the negative costs and risks of un-skilled or under-skilled staff.

What seemed an obviously right answer to the testing problem is now a problem of its own. Faced with diminishing returns, the troubled project might;

A- Train the current staff on the tool
B- Hire staff already skilled with the tool
C- Abandon the tool altogether

Good leaders intuit these options and generally acknowledge their related risks;

A- Retains the current staffs’ subject matter knowledge but will cost the team some extended period of reduced velocity,
B- Will remove the tool based impacts on quality and schedule but will both slow overall velocity as the new hires become familiar with the subject matter.  There are potentially negative impacts to the team.
C- is the head-in-the-sand approach . . . and no good can come from that unless it is followed by applying another practice to address the original issue.

None of these are simply the right answer.  The unique combination of people, problem, and constraints creates an environment where we need to rethink every assumption.  More importantly, relying on good instincts to guide problem resolution moves us further from the predictability that process and practice based methodologies should provide us.   

In my next post I will propose a scale for defining the range of practice effectiveness.

Comments