Peopleware

Peopleware is the inevitable consequence of human beings getting together to create (and cope with) complex technology.  In my experiences developing hardware and software intensive systems over the years, there are a few patterns that emerge.

 

Risk Management
Anything worth doing involves risk.  A company that chooses to play it safe and take no chances will be devoured by a competitor that has learned to manage the quality of work in the face of risk.  And the risk-adverse company will likely become the spoils of the champion. One barometer of health for an organization, as far as I am concerned, is the maturity with which risks are faced.  Suppressing risk, that is pretending the risks are not there and labeling individuals not willing to play along as "uncooperative" or  "not team players", is for children not wishing to grow up.  Another child's game is to hold weekly meetings to "admire the risks".  Mature organizations realize there are unforgiving legal and market consequences to unattended risks and actively manage them by establishing probabilities of occurrence, defining qualitatively the impacts of realized risks, and estimating the costs to mitigate risks or repair the damage should the risks materialize.  They also make decisions and act, early and often.  Before I begin a Risk Management effort, I dust off my copy of Waltzing with Bears, by Tom DeMarco and Tim Lister, as a refresher.

 

Agile Development
For me, agile development centers around the Agile Manifesto, a signed document expressing the core values of Agile practice. The Agile Manifesto is the acid test I use to determine if a specific practice is truly agile.  While not explicitly spelled out in the Manifesto itself, Agile presupposes an incremental model of software development.  I began my career as a control systems engineer, specializing in motion control. Control Engineers understand the essence of stability and dynamics, and the necessity of frequent, periodic sampling and error correction to stay on course.  Humans are capable of rapid action; in order to maintain stability and control of a development team, the control mechanism must be able to keep up with the pace of change.  Daily scrums (for rapid dynamics) and two-three week sprints (for somewhat slower changes) keeps the team humming.   A departure from the traditional control systems model, and a wonder of Scrum, is the ability for the team to self-organize.  Self-organization, along with the principle of transparency, creates an open environment encouraging team members to fully contribute and play on each others strengths.  You have probably guessed I prefer Agile over waterfall approaches; bear in mind there are some sticking points I have observed with Scrum in the real-world:

  • The integration of authentic Software Architecture practices with incremental development methods
  • Tension between "just in time" requirements elaboration (e.g. Story and backlog grooming over time) vs the need to comply with Industry Regulations and associated deadlines.
  • Scaling up measures and metrics from the scrum team level up to the organizational level.

In my experience, none of the sticking points are permanent; a little jiggling goes a long way towards helping organizations get unstuck.

 

 


The Squeeze
I remember the threat from the VP of Sales, "close this deal or we close our doors".  Once the deal was closed, the death march began.  Rewinding a few years prior, I recall orders from the CTO of another company I was working with to "fix all of the outstanding problems reported by our Customer, or else".  At the time we were thrashing, repairing failures reported from two other customers, who we were directed to ignore.  Anyone who has been in the technology business as long as I have has felt "The Squeeze".  The plates of the vise inch closer, and we howl at each click.  Every time I have been caught in the squeeze, I can trace the events back to a misestimation, a misunderstanding of the work involved, a mismatch between the customer needs and the team capacity, or some other quantitative "mis-take".  As an industry,  Software professionals are notoriously horrible at estimation of work based solely on high level requirements.  In Scrum we don't even pretend to estimate in terms of anything tangible, we invent the abstract intuitive unit of "story-points" and call it a day.  So when the VP of Sales closed the deal, he did not have the wherewithal to realize we now face our next biggest problem with keeping our doors open,  limited engineering capacity to deliver on our contract.  The CTO, thrashing from one unhappy customer to the next, dealt with the fundamental misestimation of our support needs and quality problems by adopting a "squeaky wheel" approach.  Both cases were dismal.  Not only for the executives, but especially for the developers. 

It has been demonstrated programmers will optimize their work to meet unambiguous objectives.  So if you ask a programmer to write a module to accomplish some task while minimizing lines of code counts, and ask another programmer to accomplish the same task as quickly as possible, each will succeed at their assigned objective.  In a squeeze, however, there is the dilemma ("a pair of opposing lemmas").  Repairing the problems of one customer, at the expense of another, only to have priorities reversed a week later does not constitute clear objectives.  Nor does the demand to get the work completed as fast as possible, against all odds, so we can ship.  Death march teams, and their leaders, may succeed in shipping on time.  But usually not without significant quality problems.  And they will often leave the company, feeling burned out and bitter.

To avoid the squeeze, it is best to remember that software is developed by people.  People do things like take vacation when you least expect it, go off and get married, break a leg, get sick, take a new position, or get fed up and leave the company altogether.  People also need lunch, training, appreciation, clear objectives, and support.  Software development is easy when there is plenty of time to get the job done and light pressure.  It is when the sales spike is imminent, the time to market is shrunk, the subject matter experts leave, the realization that the software is going to take longer to develop than anticipated hits,  that we feel the squeeze.  At those times it is best to remember our success relies on the strength and resilience of our people.