Originally finding popularity as a concept in the tech space, ‘agile’ has evolved to be a commonplace buzzword among the wider audiences of HR, management, and consulting. The word itself has become quite agile in function, and when used in the context of organisation design, there are even further distinctions in the definition of the word.
We can view Agile (with a capital ‘A’) as being the approach to using small multi-discipline teams to tackle large complex problems, whilst agile (lower case ‘a’) is the mindset required in other areas of the business as they support the core and respond to Agile team requirements. Some of the main differences are outlined below:
The question ‘do we want an agile organisation’ should be rhetorical, as with the current business climate there are very few who will answer no. However, Agile approaches are rarely needed, or even appropriate everywhere. This, of course, then begs the all-important question:
Where in the operating model do we deploy the Agile approach?
Start with the work
To answer this question of where, it is important to have a robust view of the work needed to deliver the strategic intent of the organisation.
In addition, an organisation needs to have developed an agreed version of the high-level Value Stream which illustrates, in no more than nine steps, the flow of work that creates value for the customer. With the Value Stream laid out in front of you, you can begin to answer the question ‘which value creating steps of work will better deliver our strategic intent if we deploy an Agile approach?’.
As you make these decisions, keep up front and central the underlying philosophy of Agile:
Small, self-governing multi-discipline teams working in close cooperation with each other and their customers to address large and complex problems.
In our experience, most Value Streams begin with some form of need identification and will often move into work relating to design and development, before moving on to going to market, production, and possibly service. In this generic example ‘It’ can be anything from a product such as a car, a phone, white goods, or FMCG, to a service such as online shopping, insurance, etc.
Underlying design principles before implementing agile
Just because we are considering Agile as part of our design, there is no reason to discard the principles we always apply when we are thinking about where to place boundaries around core work as we build the structure. These are some key points to consider as some of the foundational principles are applied:
1. Create boundaries around whole work
Don’t overly fragment the core work in the Value Stream, this will create barriers that will impede the successful deployment of Agile approaches.
Example: In our generic Value Stream, keeping identify need, design, develop, and test together will allow Agile teams to scrum around a full Design For Manufacturing & Assembly (DFMA) process.
2. Organise the structure around the core work, not the people.
Don’t confuse work boundaries with jobs. This could easily lead to Agile Teams missing out on valuable capabilities or experience.
Example: Agile Teams working between the identify need and test boundaries will benefit from input from expertise in the go-to-market, make, sell, and service boundaries.
3. Align the approach to the work to the needs of the work.
Don’t design to implement Agile approaches in a boundary that needs standardised, repeatable work processes. In those boundaries where you need to optimise profit and losses or costs, lean processes, self-managed teams, or continuous improvement approaches are often far more appropriate.
Example: In the manufacturing/production make boundary where cost, quality and cycle times drive the profit and losses. However, in the sell or service boundary the customer experience is critical.
4. Create manageable boundaries.
Don’t blur the boundary between where Agile approaches will be deployed and where other approaches such as continuous improvement will used. You can’t be just ‘a bit’ Agile.
Example: Don’t create a situation where a manager of core work has to lead more than one approach to work.
Read more: What is the Manager’s Role in Agile?
Concept design
If we were to apply these design principles to our generic Value Stream, we may then decide on three high level boundaries to place around work.
- An Agile incubator: Sections off the identify need through test parts of the Value Stream. Focused on designing innovative revenue-generating solutions.
- A Go-To-Market boundary: Generates demand and sells. Focused on generating revenue.
- A Make and Service boundary: Focuses on cost, quality and cycle time.
At this point in our organisation design work, we have got to a high-level Concept Design for the structure. We also have boundaries around the work to which we have applied some design principles to decide how that work might be approached, including where we might deploy Agile approaches.
As we move into Detailed Design, we can build out from this Concept to identify the teams, roles and ultimately the jobs that will be required to do the value creating work at each Value Stream step.
However, our greater challenge relates to the design of the management systems and mechanisms necessary to govern and manage this hybrid organisation. We know that the mechanisms and inherent skills and capabilities needed to lead and manage an Agile incubator are different to those needed in a go-to-market structure, which are different again to those needed in an optimised P&L/cost structure.
The challenges stem from building these management systems and mechanisms, particularly the mechanisms necessary to manage across boundaries with different approaches to the core work. Leadership must also ask itself how to address the implementation challenges.
Peter Turgoose is a Senior Consultant at ON THE MARK, a global organization design consulting firm and leader in collaborative business transformation with offices in the US and UK. He is a Chartered Occupational Psychologist with over 30 years of experience in applying behavioural psychology for business.
Comments (1)