This is the part I don't understand. What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months?
What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a trend or adjust for changing external conditions, I understand. But for software development?!
At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.
Different code bases in the org might even have different process certifications they have to follow, eg in medical software or some other industries. In those cases it’s downright impossible/illegal to give every team access to every repo.
SAFe is supposed to solve this. I haven’t heard anything good come out of it though so far, so I find this thread very interesting.
This requires teams to have slack/contingency time in their plans. That’s important.
Of course, there will always be situations where you don’t spot a dependency until you start coding. But in the loosely-coupled mode, that is what happens every time you have a dependency on someone else, ie you have no opportunity to spot in advance. Worth some planning exercise you get an opportunity to spot the dependency and deal with it gracefully, even if you don’t catch 100%.
But yeah, if there is no benefit to spotting early because the other team doesn’t have slack for the Q, then less point in planning in advance.
On the estimation side of things, I've worked with teams that do estimates in concrete hours, days, weeks, etc, and teams that work in abstract feature points, bushels, etc. The number one factor for whether the estimates are successful is the time spent before providing the estimate to figure out what the actual scope of the task is. If you've planned and estimated a task and didn't discover the cross-team dependency during that planning, you've failed at planning. It happens. It sucks. It should be very rare.
I've worked with teams where "sprint planning" every two weeks/whatever cadence is basically an entire engineering team getting pulled into a room for a morning, the manager/scrum-master/whatever pulls up their backlog and starts picking tasks off the top. The team is expected to provide estimate efforts on the fly in the meeting, and then expected to spend the next two weeks perfectly executing on the work they've committed to. How in the hell is a process like that going to allow people to really think through the issues that are going to arise (like needing an API change on another team, or even verifying that a 3rd-party API is compatible with what the task is trying to achieve)? These teams constantly run into the issue you've described and it absolutely sucks for everyone (the business, the managers, the developers), but the process just keeps being adhered to. Maybe in the post-mortem someone will say "we need to do a bit more analysis before doing estimates", and the outcome is that during the next sprint planning session the SM will say "HAVE YOU REALLY REALLY REALLY THOUGHT THIS THROUGH?" but... they're still doing analysis on 12 new tasks blind...
If you can get a bunch of people into a room and plan out what everyone on a software team is doing for the next three months, there's a pretty clear cap on how creative or adaptable the work can be. What is everyone doing for the rest of the quarter? "Executing"? Just filling in the "obvious" implementation details to program exactly what they're told?
Getting a clearer picture of the next 3 months should be a piece of cake. As a bonus once it’s planned you should get to focus without a sudden shift in priorities.
(Note: quickly, not suddenly. Bad performance in market validation should never come as a complete surprise. It always slowly dawns on you over the course of days/weeks.)
Another reason for changing priorities quickly is that the specification drawn by the product team happens to be technically very complex because it interacts in unforeseen ways with other functionality, and this is discovered early in implementation.
Basically, in product development, you're constantly running into things that either provide less value than expected, or cost more than expected. That's when you should do something else instead.
Once you have a great idea, yes, you should sink all of your effort and focus into that to get it to market quickly. But the idea is that if you start cautiously and change your mind early and often, you can actually implement the winners with blazing speed later without looking back.
Which is most orgs I've worked with.
I've got one foot in the pure software world and one foot in electronics hardware. I've worked with a number of startups, and some larger organizations and government.
The SaaS startup world is the exception here, not the rule. Virtually any business that is not "we're ready to pivot on a dime" SaaS should be able to plan 3 months out. Generally speaking, any kind of strategic initiative is probably going to take longer than that to roll out. If there's any kind of manufacturing involved then design, V&V, manufacturing, and QA are likely going to be running on at least 3 month cycles.
Sometimes things do pop up and it makes strategic sense to do a mid-quarter tactical shift to attack an extremely valuable lead, but that should be exceptional. Even in the SaaS world, people tend to jump on new "valuable opportunities" without really sitting back and assessing the cost of delaying everything else. This kind of organizational ADHD (one board member at a company called it "chasing butterflies") tends to result in a bunch of half-finished projects/products that all could have been valuable in their own right if they'd been run to completion instead of abandoned in favour of the next "golden opportunity".
That isn't "throwing things to the wall" or "mindlessly running around", that's trusting a team of professionals to make effective creative decisions.
There is however the argument of whether companies should look ahead for more than three months. And brilliant and trustable professionals don’t change my assessment that they should.
Success is far more likely if you decide on a goal, and then build feedback loops that let you learn. And in the internet age a feedback loop of a month is painfully slow, never mind three.
The company I work for hasn’t changed a single procedure or milestone. Neither have my clients. I am also not talking about predicting the world, but of predicting an internal kitchen.
This is just n = 1 but I’ve never seen a company that does it’s strategic planning in detached 2 week sprints.
If anything, if any sort of coherence exists I’d say that the previous sprint, the current sprint and the next sprint should have an understandable connection, and then we are already talking about a month and a half.
> I wager every company in the world was affected by the world wide changes right now.
Affected? Perhaps. Derailed? Not so much.
> Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
Both have their advantages and disadvantages, but I’d trust and would like to work, more, for a company that doesn’t flap in the wind.
No one in the industry expects stability like in the waterfall days, but to expect a company to change / adapt their strategy in less than a financial quarter is just marketingspeak in my opinion.
Having worked at both very large and very small companies, people who have not worked in the other just don’t understand what it is like at the other scale.