Progressive Elaboration (or, a box full of bees)
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
I have been lucky to engage in a bunch of Agile/ Digital Transformation work during recent years, and it is among the most gratifying work that I do. There is nothing quite like seeing stakeholders on both the business and technology sides tear a path straight through the labyrinth of process they have been dutifully navigating for years in order come together and pound-out solutions as one team. The term “liberating” doesn’t even capture the elation when the pistons begin firing at speed.
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
An area where these deeply established mindsets bubble to the surface is in expectations around the definition of business requirements. From my own experiences, I have identified two distinct mindsets: Bookend and Trajectory.
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
A few years ago, I was involved in an intensive engagement that combined an Agile transformation with a major platform integration. Great people, flexible software, engaged leadership… we were well-positioned for success. The line-level resources took to the Agile methodology very quickly, appreciating the sprint-to-sprint cadence and the focus on prototyping solutions. Our business stakeholders as well, fully embedded with the team as Product Owners, quickly learned how to wield the Agile process to further their own product agendas. On both those levels, where resources had their hands on the work every day, maturation to a Trajectory mindset occurred in a smooth and organic fashion.
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
The team began to utilize the following analogy to explain the situation:
- 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
Being all about self-awareness and transparency, the program team, led by our esteemed Product Owners, tried continually to explain this situation to senior leadership. But for reasons none of us clearly understood, the message wasn’t getting through. Only now, after much reflection, do I recognize that the underlying disconnect wasn’t the content we were transmitting to senior leadership, but the fact that they lacked the mindset to understand and accept it. Locked in their Bookend view of the world, our explanations about the increased complexity and depth of integration all just sounded like so much complaining. After all, we know where we started, and we know where we will end up, and everyone signed up for this plan, right? Within that context, all the talk of complexity begins to sound like an attempt to dodge responsibility and stall for time. Within a Trajectory mindset, this makes perfect sense — we learning as we go. But in a Bookend context, our messaging had no framework to stick to.
Lessons for Leaders
The lessons here is clear. A reliable strategy for mitigation, less so.
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
The elaboration of business requirements is among the most pivotal components of any product development initiative. Whether you choose to engage in this process via a Waterfall or Agile methodology is a question of the team, the enterprise, and the job at hand. Regardless, there must be shared understanding across the program — including with senior leadership — that we don’t actually understand the level of effort until we burn associated analysis all the way to the ground.
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.
