Rebuilding the Enterprise - Software, Hardware and Peopleware Migrations for the Systems Architect

9/07/2015

On Evolutionary Thinking

9/07/2015 Posted by William Berry , , , No comments
As is not uncommon, I went on a pretty hard Twitter rant the other night. Aimed at the industry in general, I hit squarely on a few of the trappings of current software/technology business practices. The problem was that my approach was overwhelmingly negative, and while negativity serves to provoke and stir up controversy, it more often exacerbates the problems at hand as the targets of criticism simply entrench themselves deeper. Additionally, I was missing heaps of context that, in hindsight, makes my point complete. So, the series of blog posts that follow are simply a flushing out of my prior rant. For the sake of accountability I will start each post with my original thought, tear it down and then reshape it into the proper thesis it should have been.

***

Controversial statement: 
"You don't understand that change is best executed through evolution not revolution."

What I should have said:
"Evolutionary thinking leads to a culture of sustainable, perpetual and effective change."

All organizations are multidimensional.  As an agent of change, it's critical to consider the sum of an organization's vectors.  Given that it's entirely possible overt pressure applied to any one dimension of the business can be adequately countered by another, it is reasonable that change leaves an organization nominally on it's original trajectory.  This IS the reason why organizational change is so difficult.  Reinvigorate customer service without coaxing IT and Engineering to enhance the software that customer service uses to communicate and things quickly falls back to their old ways, even in the face of substantial leadership or process change(read revolution).

Much of today's software business chatter continues to drone on about being Agile or Lean or Scrum'ing and the whole space is completely awash with crap.  The basic premise is that we pay someone to come into our organization, teach us a prescriptive approach (or proscribe current practices) to creating value or optimizing or innovating and suddenly we'll just be there - efficient, optimized and innovated.

At a sufficiently large scale, using a prescriptive approach like today's "Agile" will lesson overall organizational risk; however, it deeply concerns me to see small and medium business, investing wholesale and blindly in all the ceremony of Agile/Scrum methodologies.  The reality is that at the SMB scale, bespoke and evolutionary approaches to process innovation are capable of yielding much better results.

While I'd love to offer a simple "throw the baby out with the bathwater" approach (then the inanity of prescribing a fix for prescribed "fixes" would go totally Meta), things just aren't that simple.  The crux if the issue is how to get back to what agile was (before it became "Agile") and iterate differently on those original concepts.

In the beginning of agile, it was about people and process and valuing the former over the latter.  Then the consultants, trying to sell finish lines and succinct capsules of product (because that's what businesses want to buy) came along and converted culture into recipe.  With recipes in hand, cultures are disrupted, processes standardized and like so many a suburb, the loss of organic individuality and creativity is vacuumed out of our organizations for the sake of stand-ups, points and burn-down charts ... which are simply a projection of agile using phase-gate goggles.

How then do we teach our organizations to think for themselves?  How do we get our peers thinking about capturing the essence of change and not its outcomes? How do we build a system of metrics that change as the business changes and become glaringly irrelevant as their usefulness wanes?  How do we stop looking to copy the success of other organizations in place of finding our own?  If you are thinking at this level then you are probably well on your way ...

***

In case you missed the beginning, you can find Part 1 here: Valuing Developers Over Intellectual Property

0 comments:

Post a Comment