One size fits none
Long-term planning in a start-up is very different from planning in a multinational. What works for a 3-person product team breaks down in a department of 35.
The type of organization clearly defines the software delivery tools we have at our disposal.
Yet, when we read about planning and software delivery methodologies, it often sounds like the authors aim for a one-size-fits-all approach. "Here's why Kanban is great..."
Business books and frameworks are an abstraction of what worked for their author. Over several years, across multiple teams and projects, the writer has gained valuable insights and developed a system. But that system is very much a reflection of personal experience.
Bi-weekly demos were obviously invented by someone who had interested stakeholders. They are useless when inviting business people who only care about the finished product.
Sprints work in environments where the next few weeks are pretty predictable. They are counterproductive in a company where priorities change every week.
Agile software development, with its feedback-and-adapt cycles, is pointless in a fixed-price project where the scope is defined upfront.
Whenever I hear stories lamenting a failed "Agile transformation", I can't help but wonder whether they were trying to fit a square peg in a round hole again.
All frameworks have their limitations, and knowing when to apply which tool is 50% of success. Knowing when not to use a tool is the other half.
So, let's look at a set of companies of different sizes and see which tools to apply.
Start-ups
Start-ups are often described as dynamic, which is code for chaotic stress. They are understaffed and unstable. Decisions made today won't necessarily hold tomorrow.
The worst thing a start-up can do is apply a rigid framework with fixed milestones. To capture the magic of the start-up rock'n roll, the team needs to optimize for flexibility while ensuring they still get things done.
These teams lack resources and capacity, but they have a communication bonus: there are never too many cooks in the kitchen. Decisions are fast, and teams are easy to align.
Start-ups need to leverage that superpower by working in short, focused bursts. Rather than thinking in multiple parallel projects, they need to think in sequential blocks of solving one problem at a time.
Tools to apply: Short sprints with clearly defined goals. Iterative buffer planning. Focused backlogs.
Scale-ups
Once an organization starts growing, the game changes. The engineering team breaks up into multiple product teams, and communication lines grow exponentially.
Scale-ups want to hold on to the start-up communication superpower but need to add more structure. The worst they can do is stick to a single large team. Find products or logical components and build small teams around those. When done well, a single product manager can drive the vision.
Long-term planning in scale-ups is still rather straightforward, but inter-team alignment through a centralized roadmap becomes crucial.
Tools to apply: centralized roadmaps, small dedicated product teams, a single product manager
Agencies
Agencies are a special breed of company. They are mainly project-driven. While they could work in sprints, there's a real risk of getting "lost in Agile". There is no point in weekly demos if the client only cares about the end-result.
Agencies mainly need to get good at project management, more specifically at developing multiple projects at once. Agencies rely on deadlines, buffers and estimates to navigate their customer's whims, expectations and surprises.
Instead of building a roadmap, an agency needs to master capacity planning.
Tools to apply: project management, written specifications, capacity planning, buffers
Large corporations
Finally, large corporations deserve an entry on this list. No two enterprises are the same, but they can all be considered the antipode of start-ups.
Large companies have plenty of resources and a headcount that will make a start-up blush. Enterprises can throw millions at a problem other companies wouldn't even think about. All that power comes at a price, however. These kinds of companies lack flexibility and decisiveness. What takes a start-up days can take an enterprise months.
An organization with hundreds of employees needs plenty of managers. On top of that, there is often a layer of middle management managing the managers. Such a setup is necessary to streamline a gigantic workforce, but it leads to slower decision-making and conflicting opinions.
Large companies, by definition, suffer from too many cooks in the kitchen.
Teams always have multiple stakeholders, and pleasing them all is challenging. While developers love to ridicule frameworks like SAFe or LeSS, aligning a legion of stakeholders, manager and knowledge workers requires rigid frameworks.
Tools to apply: clear hierarchy, written specifications, a single unified roadmap, or a heavy-weight delivery framework
Company size plays a significant role in the effectiveness of your software delivery process. Rather than aiming for the book knowledge of "industry-standard" frameworks, be critical of the tools you use.
Ask yourself: do my tools still fit my company's size?