Strategic Planning in an Agile, Lean, and Design Led World
Many of us work with a multitude of the latest and greatest best practices to deliver great products that meet user needs. Some examples are Agile, Lean, Design Led, and the “Spotify model”. In this world, what is the best way to do high-level project planning that may span squads or tribes? When is something a hill vs. an epic? What is a strategic initiative?
At some point, any large team needs to do high-level or “strategic” planning. Planning identifies key goals for a broad team while also enabling the ability to report those goals and the status of reaching those goals to leadership.
Modern techniques of Agile, Lean, and Design Led provide a multitude of terms and “tools” teams use to accomplish goals. It is difficult to separate the tactics of how we reach our goals from the methods of defining those goals. Some example terms/tools are: Minimal Viable Product (MVP), Hills, Epics, Stories, Tasks, Strategic Initiatives, Goals, Themes, Plays, Releases, Milestones, etc.
It is useful to abstract out a few key concepts when faced with large planning challenges. Specifically, Tasks. For the purpose of this blog, a Task is used in the most generic sense. It is not tied to any particular tool or practice.
A task has:
- Someone responsible (owner).
- Target dates for delivery.
- Teams that deliver for the person responsible (resources).
- Optional sub-tasks. A task can be broken down into smaller scope.
For high-level planning, it is important to be able to define the highest level tasks that will enable you to execute your strategy.
High-level tasks should:
- Enable a product-market fit.
- Help customers accomplish their jobs-to-be-done.
- Ensure teams understand how their individual tasks (smaller scope), fit within the broader scope.
In order to best communicate high-level tasks to teams and leadership, it is important to not have too many which may dilute the message. In many cases, three high-level tasks plus a 4th — Technical Foundation — is a good number. There may be some science behind this, but I’ve simply found it to work well in practice. Also, 3+1 is used by IBM Design Thinking for Hills, but it is not specific to Hills and can be generalized.
High-level tasks could be defined for a Squad, Tribe, or Company. There may also be a key date content must be shipped. This might be a conference or date that has been committed to key stakeholders. Alternatively, the set of content or features might be well defined. Either way, content, dates, and resources will constrain the plan. With all those variables in mind, it’s time to try to define three high-level tasks. The team may find that the tasks are too high-level to serve any purpose. That is ok. The intent is that they are the strategic buckets that you will break down into sub-tasks (again, “tasks” is used generically).
Remember, as high-level tasks are decomposed, they will need target dates, a leader responsible for delivery, and a team responsible to do the actual work. Part of the team’s work will be breaking down those sub-tasks into further sub-tasks.
With this process in mind, somewhere along they way, a team will be responsible for a set of tasks and may want to use their favorite process or sets of tools to deliver. In short, they need to figure out how to deliver on the plan. This is a positive indication of an empowered team that is motivated to deliver in the most effective way possible. The leader and team responsible for a task (and sub-tasks) should be empowered to execute however they feel is most efficient and likely for success!
In summary, high-level project planning is pretty simple. High-level tasks are defined and get broken down into sub-tasks. All along the way, the tasks will have people responsible for delivering on those tasks within desired target dates with some set of resources. Don’t let the terms, tools, or methods get in the way of this simple pattern. Once tasks are defined, enable teams to call them whatever they want (Hills, Epics, Stories, etc.) and execute! Terminology isn’t important until teams are thinking about how to deliver. High-level tasks are simply a tool to organize the more detailed descriptions of what needs to get done.
Let me know what you think and share your insights in the comments!
