Progressive Elaboration (or, a box full of bees)

Photo by Damien Tupinier on Unsplash

Highly complex tech/ops solutions lend themselves to progressively elaborated business requirements. Ensure the team and leadership understands the effort and risk to fully define those, and the low efficacy of any estimates provided before that process is complete

Enterprise Agile Transformation

But Digital Transformation can also be fraught since legacy attitudes and expectations can run so deeply and pervasively throughout an enterprise. Make no mistake, every Agile transformation initiative exists on a tightrope. Even as your new-fangled approach delivers mighty results, and your own charm offensive converts ground-level resources into believers, there will be entrenched mindsets and powerbases perpendicular to your path. While you might focus your attention on creating tactical value via your new Agile methodology, ignoring these underlying blockers can scuttle even the most tactically successful endeavor.

Make no mistake, every Agile transformation initiative exists on a tightrope

There is a phase during any transformation within which all the enterprise knows is its old way of operating. That phase begins to sunset the moment you appear and begin to evangelize. At some point in the future, accrued success will have won them all over [or at least critical mass to shift the enterprise mindset to an iterative posture]. But until that point, you are forever swimming against the current. Uncomfortable and exhausting, but unavoidable if your intention is to create fundamental change.

Identifying the Product Development Mindset

MINDSET: Bookend

We find the Bookend philosophy in organizations with a Waterfall pedigree. As is the case with that methodology, this mindset espouses that both the beginning and ending states of the project are known, and the path between them can be defined by a measurable straight line. Even in the case that the granular details of the build process might not yet have been fully fleshed-out, at least the broad strokes of the solution can be enumerated, described, and planned around.

MINDSET: Trajectory

The Trajectory mindset describes a more Agile approach. Whether that attitude became the norm because the enterprise is natively Digital, or through the hard work and reprogramming on an enterprise Agile transformation initiative, this mindset revolves around an acceptance of what we do not know. While we might have clear, shared understanding about where we are today, and a general shared vision for the direction we want to go, we all understand that the specifics of that path are unknowable until we walk it together. In this case, the certainty of, “We know exactly where we are going” is replaced with thoughtful structure and controls that allow the process to unfold organically in a carefully managed fashion.

We all understand that the specifics of that path are unknowable until we walk it together

Yes, Bookend is more associated with a Waterfall environment whereas Trajectory is found in shops focused on Agility. But it would be a mistake to simply apply the mindsets to the methodologies and call it a day. Remember, these mindsets are deeply-set within the enterprise. Just because a company is currently operating from an Agile playbook does not necessarily mean that they have fully embraced the Trajectory mindset. And that is where the trouble starts…

Trouble Brewing

The place where we got into trouble was with senior program leadership. While those stakeholders were intellectually on board with the Agile transformation, and appreciated the value it was delivering along the way, we all barreled into a blind alley on mindset.

These senior leaders, without the benefit of simmering in the Agile process day-after-day, never accrued the hands-on experience to enable maturation to a Trajectory mindset. For them, the world was still Bookend.

From the perspective of those leaders, we all knew where we were starting, and we all knew what the solution would look like upon completion. And further, we all agreed to this plan. The entire program team would, I believe, agree with that assessment, with the caveat that our understanding was limited to a coarse level of granularity, with many details yet to be clearly defined.

The fulcrum of our disconnect with senior leadership was on the volume of work/risk associated with the gap between our going-in high-level understanding, and the granularity of detail necessary to power a successful development process. In hindsight, senior leadership seemed to think of that gap as just the icing on the cake. Whereas at the team level — more every day as the complexity of our technical/operational undertaking came more fully and sharply into focus — we came to realize that the gap was actually all cake.

The fulcrum of our disconnect with senior leadership was on the volume of work/risk associated with the gap between our going-in high-level understanding, and the granularity of detail necessary to power a successful development process.

Ace Moving Company

  • Imagine you own a moving company
  • A new client contracts with you to move and unpack a dozen boxes in a new office, and have it ready to go for Monday morning
  • Seems clear cut: You can see all the boxes, You know how many there are, and you have an address for the destination of the move
  • Moving day comes, you truck the boxes to the new location and begin unpacking
  • The first box contains a few lamps and desk accessories. Lay ‘em out, plug ’em in. This is going swimmingly — you’ll be done in time for a late lunch!
  • The second box contains 7,500 ping-pong balls
  • Ummmm… Is there a ping-pong table? Where do they even belong in the office? How are you going to store these things? Is the Container Store on 23rd St. still open?…
  • The third box is full of angry bees

You get the idea. Just because you can see and enumerate the boxes doesn’t mean you truly understand what is inside of each. And if you don’t know what is inside, there is no way you can accurately estimate the work effort and risk associated with unpacking. Not until you have opened each one and thoroughly cataloged its contents do you truly understand what you’re up against. Waterfall would have you do this upfront and Agile suggests that you do it along the way, but the underlying reality is the same: you don’t know, until you’ve done the work to know.

No Mindset to Stick To

Lessons for Leaders

For sure, we need to expose this mindset paradigm to senior leadership at the front-end of the process. We must ensure that — at least intellectually — they clearly understand the Bookend and Trajectory mindsets as well as the risk that lies between.

What we know from experience, however, is that understanding something intellectually and living it during the stress and confusion of product development can be very different things. Those who have the opportunity to marinate in the Agile process through direct, daily interaction with the team are well-positioned to make this mental shift. The organic nature of Agile, as well as the way that it ties our fates together, serves as a potent classroom. For the senior leader without the benefit of that daily exposure — and all the additional pressures and distractions that come with senior leadership — the conversion is far less certain.

I wish I could tell you that I have a silver bullet, but sadly, no. From my perspective, this scenario shakes-out to the same attributes that make the difference in most scenarios where leaders are concerned. Hire people who are smarter than you, and celebrate their intelligence. Push authority down in the org, such that those with their boots on the ground have the tools to address the challenges and opportunities they discover there. Listen to the team, particularly when the background noise is at its most distracting. And most importantly; trust your people. Unless their jobs are something you can do on your own, they represent your only path to scale. If you don’t trust your people enough to believe, support, and negotiate in good faith with them in a situation like the one I described above, you have a relationship that is broken. Better to cut that person loose and go find someone who you can trust than to continue strangling the product development process.

Final Analysis

If you choose to go with an iterative approach, work assiduously to create that Trajectory mindset among the team and its leaders. And beware of those who retain a deeply-set Bookend attitude. The devil always lives in the details, and it is in those that your program will founder.

BUSINESS PROCESS & OPERATIONAL LEADERSHIP; I organize people, process, and tools to create scalable delivery to the market.