Statics and Dynamics
Way back, about 35 years ago, I vaguely recall an Engineering course in Statics and Dynamics that was particularly difficult. I’d be lying if I said I could recall any of the formulas from the course, and the textbook is long gone, but I do remember that, well, static analysis was pretty lightweight compared to the sophistication of the dynamics half of the course.
Oh, and the final was brutal.
You’ve probably seen the video of the Tacoma Narrows Bridge, a compelling example of the difference between statics and dynamics. From the static perspective, think about the steel beams and concrete and calculate the load they could bear, you’d think it’s a pretty straightforward problem (Calvin’s dad has statics figured out). Throw in things like forced resonance and aeroelastic flutter though, and well, they just don’t build bridges like that anymore.
For good reason – July 1, 1940, was pretty brutal for that bridge.
As I look back over decades of experience working with teams and process and methodology, I’ve come to believe that we are largely naive about the challenges, and we try to manage a dynamic problem through an overly-simplistic, static analysis.
For a few years, I was in the business of process improvement, which is generally characterized as installing a standard process into an organization (I would never do that today). Most implementations of agile that I’ve seen, again, are standardized implementations for an organization to use, project after project. I’ve spent time in recent years helping teams get things done despite the ‘agile’ process that’s in place.
Deploying a standard process is an easy point for a consultant – you don’t need to understand a client’s culture, or even their domain, to rattle off a rote list of steps or templates that you picked up from a book or a few days of training. While you’re with the client, they might even experience a bump in performance, but it’s more likely because people are actually talking about how they are getting work done, not any value you’ve added.
The problem is, a static process actually sets teams back. They will soon discover it’s too bulky for some work, it’s insufficient for other projects. Today’s agile is no different from past fads in this regard.
Most important, though, is the fact that we’re humans, and the interaction on projects is highly dynamic. Galloping Gertie looks positively staid compared to some projects I’ve been on.
We can do better.
The first step is for everyone to acknowledge the dynamics of projects. Each one is different, and even on a single project, circumstances can change instantaneously.
The second is to understand that dirty little consultant’s secret: every team has within them the capacity to think through and select how they will deal with each challenge that comes down the pipe.
We need to start using those brains, the very things that make us different from the machinery and the industrial processes that we too often try to map (a.k.a. force fit) to human endeavours like projects.
It’s actually easier than you might think. Understand the principles of collaboration, appreciative inclusion, shared goals and effective change management, consciously choose how to realize these elements on your next project, and you will deliver better results faster than by slavishly following a static approach to resolve a decidedly dynamic challenge.
Even after that consultant is out delivering the same damned static crap somewhere else. – JB