Planning – Part Two: The Scaled Planning Process
Build a scalable planning framework around your company, don't force your company into someone else's.
My last post took a deep dive into the theory and concepts behind product-centric planning. The five facets described in that post offered a broadly applicable framework to apply your unique planning process. You can think of it as the intro to Macroeconomics SparkNotes with this and the following post being the complimentary Into to Micro. Outcome, Scope, Capacity, Ownership, and Organization apply to every company but how individual companies put them into practice is unique to that company specifically. And this has always been my one hangup with the Agile school of thought. Inflexibility of execution.
The theory and concepts post provided us with the broad strokes and baseline approach to planning. This post uses examples from how we plan and walk through the nuance of applying a scaled planning paradigm to your company.
Photo by Lukas Tennie on Unsplash
We operate as an agile product development organization so exploring agile as a foundational model is a logical place to start.
Every single day of my professional career has involved the Agile methodology. Starting as a Project Coordinator at a multi-billion-dollar medical software company, the immediate plunge was quite shocking. I had never heard of Agile, never worked in the tech space, and my only experience with any sort of planning was very much waterfall-centric in the residential construction contracting industry. Learning the basics and understanding the importance of a homogenous system requisite to tie hundreds of scrum teams together to right size planning and capacity management against a multi-year timeline was like appreciating a symphony playing in perfect harmony, just with way more politics and personalities. It was not, however, without its hiccups and pitfalls but the value was abundantly clear. I took what I learned and immediately applied it to a much, much smaller company that was only a few good years post garage start-up phase with a multi-discipline engineering org, half of whom had never heard of Agile, scrums, story points, etc. My job was to dismantle the current PMO and start from scratch. Step one: Agile basics for all.
This starts with defining your working team, ie. Scrum Team, and the most granular level of work. We got practice writing user stories, driving single outcome tasks, writing acceptance criteria, defining requirements, and got comfortable using story points. We then brought it together and planned sprints, refined our backlogs, and neatly bundled work into epics. And this is where it stopped.
While effective at a team level, the company was unable to deliver any new products to market. Value was being created and work was being continuously delivered every sprint, yet nothing was actually happening at a macro level. The reason? The company did not plan in the same way that the teams did. As an example, there were seventeen new products or enhancements in development at the same time, all in a new facility that had yet to successfully take a new product from concept to production and an engineering department of roughly 30 engineers across the hardware and software discipline spectrum. We were spread much too thin, had zero real interdepartmental processes or formal communication in place, and let arbitrary deadlines drive development. It took the purge of almost the entire leadership group to get things back on track. The first thing that the new leadership group did was enable the implementation of a standardized and scalable agile product development organization. We are currently a year and a half in and finally operating within that beautiful, homogenously organized symphonic approach. The key? Our own flavor of a scaled agile approach.
The same Agile principles of well-defined, single-outcome work driven at a capacity-dependent velocity and with a single point of focus for the given timebox apply to Sprints, Months, Quarters, and Years. A standardized concept and framework applied to an ascending timescale. And most importantly, if work is injected in, work is pulled out at any level. You can do anything you want, you can't do everything you want.
As shown above, agile teams plan and execute at the hours, days, sprints, and month cadence. High detail, fine granularity of work, and single-focused execution. Leadership plans at the quarters and years level with requisite detail aligning with business objectives and market landscape. The two meet in the middle via quarterly planning exercises and monthly planning reviews. The quarterly and yearly plans provide clear direction, context, and line of sight to the agile teams and the agile teams continuously deliver against the broader plan. Communication and flexibility of execution are driven bi-directionally and, through high levels of autonomy and decentralized leadership at the agile team level, nimble, high-velocity delivery is achieved.
The size of our company necessitates four tiers of work. Larger companies may require additional levels to tie disparate divisions or organizations together while smaller companies may only want two or three levels as additional tiers would begin to obfuscate the underlying goal, create administrative busy work, and generally detract from the team's ability to execute. Scaled Agile Framework (SAFe) purists may disagree with the flexibility of this approach, but it has been my experience that those frameworks are far too inflexible and require an army of Delivery Leads or Project Managers to execute the correct way. Ours does not.
The system boils down to two key takeaways. Define a planning process and scale the implementation of that planning process to all levels of your company. As for mitigating the administrative burden that generally accompanies a large planning process, let your tools do the heavy lifting for you, but more on that in the next post in this series.