People Laws (part 1)

“…when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in thought advanced to the stage of science, whatever the matter may be.”
                                                                                                                  – Lord Kelvin

“There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.”
                                                                                                                  – Lord Kelvin

While most will differ with Lord Kelvin’s second statement from 1900, I am somewhat more agreeable with him on the first quote.  As I try to describe the laws of development physics, I often feel that we – any of us – are barely beginning to postulate any true science.  I do, however, believe that there is value in expressing even those laws that are not quantifiable. I’ve even tried to express those laws that are based on math with simple statements of meaning. The important thing about laws or principles is that when violated there are consequences and costs.

In that spirit, I will propose a some human element laws of development physics in the next few posts.  These are not mathematical in basis and can only be quantified and optimized by trial and error, but they are no less important when ensuring agile development processes are properly structured. They work together with value statements to direct successful agile development.

The sixth law of development physics:

Optimization happens at the lowest level of active management. People, not organizations are self-optimizing.

It is important to understand that development happens at four or more levels in most organizations:

• strategy/organization level – What competencies and products, what customer segments, what resources and funding, which opportunities exploited, what threats addressed, what broad timelines
• product/group level – what architecture, what quality, what sales and support, what product road map
• release/project level – which team, what features, what deliverables, what plan
• individual/functional level – what tasks, what tools, what methods, what interactions

While agile works at any of these levels, it is best applies from the top down. It does little good to cut in half the time to develop a widget, if it still takes multiple years to get it funded. There are few benefits in developing great features if sales cannot sell them or implementation takes longer.  It does little good to make development more productive if testing suffers or the wrong tasks get done faster. Agile’s benefits only rise to the lowest level of support.  A systems view from the top is needed to reap its full benefits. 

Normally, this means that agile practices need to be at least understood by executive level sponsors.  At best, it means they believe in and actively support them. It also means that agile practices should be used in Strategic Planning, Governance and Budgeting, Project Management Offices and Teams.  Lacking a comprehensive approach, using the principles and applying the laws can only optimize part of the overall system.