On not being tightly coupled

Imagine this recent experience.  Conference call.  80 participants.  The agenda progresses, and my team comes into the spotlight with formal presentation of a request for a system change, building on several advance preparation discussions.  I connect to provide air-cover.  Probably a highly-invasive, performance-intensive, multi-system impactful change, right?

Wrong.

think.jpg

In reality, the change was minor and isolated – a modification to an already-existing web service API.  One system impacted, and all involved team members already signed up and waiting to start.  Work factored in hours, desired to drop to production in 6 weeks.  The request, however, needed a change at source, in a major legacy system.

In true fairness, when dealing with the law of large numbers, the numbers can and must win.  Integrity wins in balance over innovation.  When the organization’s overall priority is mitigation or elimination of risk, there emerges a trend toward “brute force.”  Control processes drive plans.  Criteria drive decisions.  Avoiding incident tends to minimize change.  This drives toward very large, infrequent releases of change, with long testing cycles, UN-lean teams.  Innovation discouraged…Orwellian IT. 

This is not what I want to be when I grow up. 

My teams have been agile for a while, focused on building loosely-coupled and analytic solutions that involve the end user throughout the lifecycle, enhancing and constantly re-factoring the experience based on feedback.  New ideas are welcome, and the iteration of the strategy improves the value of the product.  In partnering with Pivotal Labs, I am interested in taking that to the next, or “extreme” level.  Shipping product to production constantly, mitigating or eliminating risk because the changes are bite-sized (and easily reversible).  End users are continuously delighted by the changes which increases their engagement and makes the feedback loop even more powerful. 

How next could we could we better disambiguate those bite-sized changes from big legacy release cycles?  How does our own investment in highly automated dev/ops change how we build and operate product at ever-greater scale?  How do we shift insight delivery from weeks to days to hours?  Those are the thoughts I want to police! 

What are you seeing?