Taming the stream of ideas
Every company has a divide between those who think about the product and those who build it.
Salespeople won't touch an IDE, but they fantasize about new features. Product managers will stay clear of code reviews, but they dream of the next big thing.
In weak company cultures, this divide creates friction between thinkers and doers. Business people say jump, and developers ask, "How High?".
It's a remnant of how we used to work. Smart, non-technical people used to get together to refine the requirements and turn those into functional specifications. Only when the scope was defined and the budget was greenlit did we include the first developer. Of course, those projects were doomed to derail!
The separation between thinkers and doers drives developers crazy. Engineers loathe the barrage of vague, contradictory requests business people throw over the wall. "We know you are racing against the clock to deliver crazy-promise-X, but could you also quickly do impulsive-new-idea-Y?"
Over the years, engineering departments have come up with ways to shield themselves from this stream of ideas. Sprints are basically two-week pause buttons. "We all agree to build this. Now, don't change your minds for the coming fortnight, please". SAFe is nothing but an attempt to tame the idea fountain by locking work down for months-long release trains.
The problem with this approach is that the thinkers won't stop thinking just because you're building. You can plan stable four-week sprints but can't prevent business people from having a new idea during the first week.
Instead of trying to ignore the idea people, we need to channel their chaos. And that, like I keep repeating in this newsletter, requires a plan.
When I talk to technical leaders, they often struggle with channeling that stream of ideas. I understand why they feel that way. We lack the tools.
Most of what we call "Agile" these days is local optimization. We fret about the right work-in-progress limits for our developers yet accept the firehose of ideas that gets blasted at our teams.
Taming this stream of ideas is a three-step process. It's simple but not easy.
Own the plan. Business people don't have a plan. They have a wishlist. They are in no position to estimate the workload or create realistic timelines. Only tech leaders can do that. So, don't base yourself on Business' wishlist. Take control of the plan.
Close the feedback loop. Don't communicate through PI planning meetings and backlogs. You'll lose if sprint kick-offs are the only point of contact you have with the Business. By the time your team has moved their first ticket to the In Progress column, Business will have five more ideas. Get together regularly with your Business counterparts to discuss your plan and their expectations. Organize daily check-ins if you have to. Use these moments to reinforce the concept that your plan is the single source of truth. This will reveal any discrepancies in expectations early on.
Keep them accountable. When Business comes up with a new idea, use your plan to show the impact on the current work. Stakeholder Jiu-Jitsu is the tech leads' superpower. "If we drop everything to build this new feature, we'll have to postpone the Office365 integration until next year. Is that really what we want?"
Business stakeholders aren't unreasonable, but they need the guidance of a clear plan to make informed decisions. Without that, they can only guess. It's up to you to provide that framework.
There are plenty of reasons why there is a natural divide between Business and Engineering. That makes sense in most companies.
But there is never a good reason to let Business control the plan. They are in the worst position to do so.
Tech leaders need to own the plan.
That’s how you tame the stream of ideas.