I had a conversation recently with a few industry professionals who were expressing concerns about the idea of scaling agile.
Their objection was that not everybody can be agile nor needs to be. Their primary argument was that most people’s jobs are well-defined in terms of what needs to be done and what the outcomes should be. Therefore they don’t need to work on teams, have defined “missions”, and the teams don’t need to be cross-functional. There’s some truth to this, but ignores the upside from organizing work around cascading missions.
There’s been this tendency to kind of munge agile together with lean manufacturing and lean startup or lean innovation. There’s a lot of talk about managing complexity and uncertainty and that agile means being entrepreneurial.
To be clear, while one can get such benefits from being agile compared to organizing work purely by function, not all parts of an organization need those specifically.
What are cascading missions?
Organizing by cascading missions means putting everyone on teams with missions that “roll up” to a company’s strategic priorities. The goal is to be able to draw a straight line from people’s work to desired outcomes. It means becoming more efficient at executing on the current priorities, while building in the ability to change work based on new information.
What are your company’s defined objectives over the next 1-5 years? They typically might be:
- Revenue targets
- Cost reduction
- Profit margin
- Growth rate
- Market penetration
- Internal issues such as employee retention or engagement.
- Customer satisfaction metrics
These objectives should have specific quantifiable outcomes, with goals set for every year. They are the organization’s primary missions. What’s the next level down? Perhaps business units and then products per business unit, while back office functions have missions to serve internal teams’ work. Next you might think “We’ve got one thousand people and we need to group them into teams and carve up the work into missions.”
Impactful organization
This is a more impactful way of organizing the company, rather than carving work up based upon function. In the end, most teams will look the same, as if they were carved up by function, but only because the mission dictates that. In other words, if a team has a mission that requires building particular software product functionality, the team will likely be composed of all software developers. On the other hand, if a mission requires a team to investigate what functionality will increase customer engagement, functions other than developers would be required.
Dealing with complexity and uncertainty is built into the organization. More uncertainty requires more diversity and interdisciplinary skills. Back office functions can even end up on teams where execution blueprints are not yet defined or change frequently. This helps delegate decision making closer to where issues occur.
The goal of organizing by cascading missions is to be able to draw a straight line from people’s work to desired outcomes.
When you scale based upon functions, you are likely reinforcing silos. Management of functions protects their resources independent of achieving shared objectives. You end up cascading tasks that one hopes align with organizational priorities. Tasks are given deadlines. Groups are rewarded by being on time and under budget, regardless of whether objectives are achieved. Managers are mired in the muck of managing individuals, rather than strategically allocating resources based on evolving market needs.
The best part is I don’t believe organizing by missions is more work than organizing by function. I think that we are just more comfortable with the hierarchical, command and control style because it’s what we’re used to.
If you’d like to learn more about scaling agile I’ll be doing a livestream on the topic on August 22 at 11am PST. https://us06web.zoom.us/j/87672424063