Software development bottlenecks, take 2

I earlier provided a link to an article on (software) application development bottlenecks.  I was quoted twice in the article along with other sources like Gartner and Forrester Research.

How to Deal with Software Development Bottlenecks - Mike Russell

Although I was quoted twice, I provided more information than made it into the article.  In this insight, I’ll provide some of the other perspectives.

To recap, here are the two segments that were published:

Application development speed and capacity are usually NOT the issue.  The issue is that the business users’ requests are not prioritized and valued such that priorities are established and existing capacity is dedicated to higher value work, yielding better use and ROI of scarce development time.  Every business has finite resources.  If benefits/value are not established, there is no way the business can rationally make decisions about how to use scarce resources, especially application development.  Without valuation and associated prioritization, priorities are usually established by politics and the infamous “who yells the loudest” methods.  Also, there are no curbs on “business demands” because no one knows what is reasonable.

The craft of business analysis has degenerated into requirements writing and management in many companies.  GIGO (Garbage In, Garbage Out) still applies to application development.  If businesses don’t make an effort to truly understand who the customers are and what they need, then products are often based solely on internal thinking (and therefore often assumptions instead of facts) about what customers need.  In this case, applications development can speed up 1,000 times and still be a waste since all the effort will be invested in delivering the wrong thing.  The initial thinking should be treated as an assumption and tested by market feedback.

Here are some of the additional, unpublished perspectives along with some explanation of the “why” I made the statements:

Why not just increase development capacity if there isn’t enough capacity to meet demand?  The answer is usually “that would cost too much!”  But what if all the efforts have positive ROI?  That would mean that everything developed brings in more than invested … wouldn’t everyone want to expand capacity in that case?

This is a thinking question that should lead to issues like not identifying value, inability to identify ROI, and the like.  Those issues probably also mean that only cost, not benefit or value, is identified and tracked.  The leadership question is then:  Why bother with all the effort to estimate and track the former if we have no clue about the latter?  Focusing only on cost leads to arguments about cost and then more focus on cost.  A business needs to focus on profitable revenue growth, not cost alone.  Focus on cost alone will lead to poor business decisions.

Not prioritizing and valuing work is an abdication of leadership.  Trying to get all things done for everyone and putting the blame on the technicians for not getting enough done is a shell game where everyone eventually loses in some way.  Leadership responsibility is to identify direction and prioritize the highest value efforts that can take the business in that direction.

Self-explanatory … and leadership is both “business” and “technology.”  And while we are on the subject of “business” and “technology” or “IT” parts of the business:

Anytime we segment into “business” and “technology” or other functional areas, we have automatically failed before we even have the discussion about products and services.  ALL delivery of needed products and services, whether external or internal, should have business value, period.  Segmentation into functional silos just reinforces lack of leadership and ownership for the whole value flow and engenders arguments about fiefdoms.

“Aligning business and IT” has been a perennial item on the top priority lists of CIOs.  One of the reasons it is there is that the CIOs and their counterparts are thinking in silo terms and trying to sort out competing silo priorities presented to IT.  Since silos typically use different prioritization approaches, there is no common ground on which to base prioritization across silos.  If the overall business was run based on what customers value and what the business needs to do to deliver that value effectively and economically, priorities would be clearer and there would be few alignment issues.

Application development metrics are often vanity metrics  … metrics that are easier to find but that don’t relate to user/customer value delivered.  Utilization is a perfect example – what customer cares about how long someone works or even how much software is produced?  The customer cares about value received.  Output does not automatically equate to outcome.

Metrics are another area that cause business-IT silo misalignment, assuming we persist with the silo mentality, because IT often runs on different metrics that may not have any meaning to business.  That means any prioritization discussion around metrics will automatically be derailed or degenerate into non-rational prioritization schemes because silos are measured differently.  How can your business focus on outcomes and not just input or output?

Agile approaches hold great promise for many application development groups but ONLY if the full organizational “system” is considered and adjusted.  Otherwise, gains will be smaller than hoped and short-term at best.

An example:  performance management is notorious for not being aligned with agile approaches, leading to agile derailment as soon as performance management reviews/ratings penalize people for working in agile ways.  One common misalignment is when performance management (and management) focuses on individual performance while management then talks about team work and results.  What do you think will win long-term?

Agile approaches also emphasize results over activity, naturally helping with the other perspectives about value and prioritization.

Speeding up application development is rarely just about the tools or technology and more often about the human element.  Are people led, organized, and incentivized for results excellence?

An example:  if vanity metrics are used to “dashboard” applications development, then people will work to the vanity metrics rather than real results.

Multitasking is the carbon monoxide of corporate productivity.  Simply reducing multitasking can generate astounding productivity ROI without complicated process, tooling, or other changes.

A widely acknowledge problem and one that few address …


By Mike Russell