“I can’t do it now. You need to put it into the Backlog.”
I’ve heard this a number of times from Development Team members when their line managers (e.g. the Test Manager or the Development Manager) suddenly approach them to do unplanned work. I’ve also seen managers get very upset about push-back from team members.
The reaction is strange, because I’ve also seen managers get upset when someone else (quite legitimately because of a person’s role) asks a team member to do ad-hoc work.
Agile frameworks like Scrum are designed to minimise the impact that these distractions cause by ensuring work is value-prioritised through the Product Backlog. It even has a Product Owner in place to manage that list of work and ensure that the team is always working on the most valuable thing they can at any point in time. And when any team member does ad-hoc work it is at the cost of doing work they had planned as part of the team’s Increment at the end of the Sprint. It results in waste.
But what is really going on here? Is there a better way to organise work and teams so this waste doesn’t occur? Is there a way to meet capability manager’s goals as well as those of the team and their customers?
Traditional Operating Models
Everyone is familiar with this model: capability hierarchy.
With this model, we’re building 21st century web-enabled business processes on 20th century management processes, all build on atop 19th century management principles.
It’s how most of us used to work. Some of us still do. I feel it remains a part of so many operating models because of something called “project management” – a temporary construct built to achieve an outcome. What follows is something like:
- We need to do a project
- We assemble people
- They do the work
- Then the people need a place to return, so we disassemble the project team, they go back into their original capability-based structures until they’re needed again
To assemble a team, project managers and capability managers negotiate how much time a person can spend on the project. Hopefully, the person gets to spend all their time on the project. What I’ve experienced, though, is with a “project’ mindset:
- There are too many projects to do
- We couldn’t possibly not do one project
- We have to do all the projects at once
- We’ll spread people across all many projects because we don’t have enough people
Of course, the capability manager is still the person’s boss (even though they are now part of a team with a project manager leading its delivery). On many occasions, I’ve seen capability managers continue to direct the person to do tasks that have nothing to do with the project.
I’ve seen them re-direct people to work on different projects, spread them thinner across more projects, tell them to re-do work because it’s not up to the manager’s standards. The waste due to context switching is significant.
Should the person serve their capability manager, their team, or the project manager? What structures will allow for a decrease in complexity in management of people and the outcomes we want to achieve?
Agile teams in a project management operating model
If teams stay together is an agile team, rather than disband, what happens then?
If we continue to operate under a project management paradigm, the same behaviour will occur.
Capability managers will still:
- Try and get work done (often work that aligns to corporate goals not project goals) by delegating it to their immediate reports
- Tell people how to do their work
- Tell people to re-do work (often right now) if they’re not happy with the outcome
- Give their people ad-hoc work to do that has nothing to do with the project they’re on
- Spread people across multiple projects
- Be of the mindset that if there are multiple projects, then they should all be done at the same time and spread their people across them with the assumption this is the best way to get all the work done
Project managers will still:
- Try and negotiate for more people to be on their team to produce the outcome of the project
- Compete against other project managers for “people” resources
People on teams will still:
- Be torn as to who to serve
- Still be spread be across multiple projects
Agile operating models
Agile operating models operate with a different focus:
- Put the customer at the centre of delivery. With a great product or service means improved revenue, improved compliance and a positive experience.
- Value-centred. All work is considered from the perspective of whether it adds value to customers, the business, whether its valued because of its timeliness or risk-reduction, or even if it decreases risk.
- Produce high-performing teams. Want success? Want radical transparency so that risk is easier to manage? Long-lived agile teams are one of the smartest ways to create improved productivity, efficiency and effectiveness.
There are a number of considerations when considering how to switch from a traditional management approach to an agile operating model:
- Managing people through Scrum Masters
- Managing people through Product Owners
- Supporting technical excellence through Communities of Practice
- The role of senior managers and executives
Managing through Scrum Masters
A Scrum Master’s responsibilities do not extend beyond Scrum – coaching and supporting the Product Owner, the Development Team and stakeholders, to make the best use of agile’s empiricism. However, many organisations turn their capability managers into Scrum Masters. I find this tends to happen when people feel that Scrum Master (and maybe it’s the term “Master”) means Delivery Manager and that your Product Owner is the actual owner of the product, i.e. the customer. While both of these perspectives are false, as people transition to agile frameworks, this is what tends to happen anyway.
I’ve never really found this model to work successfully. In terms of behaviour, it has its flaws:
Capability managers will still:
- Tell people what do to
- Tell people how to do it
Customers will tend to (very often in my experience):
- Want more “features”
- Want it now
- Not care about architecture or system capability
- Not understand the economic trade-offs, economically sensible batch sizes, or that the team sizes/estimates the work
- Wonder why people are in meetings all the time and not doing work
- Fail to understand that something can seem to be simple in the interaction design but be horribly complex under the hood (and hence will take a long time)
The Development Team needs a buffer between all of the competing client voices – the Product Owner. They also need someone to support them to self-organise and use agile to deliver value – the Scrum Master. When this doesn’t happen the balance agile creates between delivery, people and the framework starts to breakdown.
This operating model reminds me of a case study in which it was thought that giving developers access to their customers, even having them sit together, was a great idea. Through direct customer interaction the product that was built was heralded as a wonderful success. Unfortunately, the customers took it in a direction that they wanted over the direction that aligned with its strategic direction. Millions of dollars was wasted. The product failed to do what it was intended to do.
My take-away – don’t mistake the customer as your Product Owner. Furthermore, don’t turn Scrum Masters into Delivery Managers.
Managing through Product Owners
Another option (and my favourite) is to create agile teams under the capability managers and turn the capability managers into product owners. If these managers’ behaviour is to give people work, then leveraging the product owner role helps use that behaviour to transition them into a new role.
This model also works well when not all agile teams are Scrum Teams. The Scrum Master role only exists in Scrum.
Communities of Practice
Managing and growing capability across teams is still important.
An agile operating model doesn’t stop at changing a manager’s role. Teams’ capabilities still need support to grow and maintain/improve standards. Communities of Practice (CoP) are often the model used.
Spotify has two structures in their organisation, Guilds and Chapters.
- Chapters – cutting across teams (Spotify calls their agile teams “tribes”) and focussing on a specialist discipline like development or testing
- Guilds – cutting across the whole organisation around a special area of interest, such as web technology, design thinking or innovation.
The key to getting Communities of Practice to work is in understanding they often emerge to serve a purpose and then fade when there is no longer a need. This cycle of emerging and dying away is perfectly natural and should be expected.
It’s also important to understand that leadership of Communities of Practice come and go to serve the community at different times with its different needs.
If the Community of Practice lead is also part of a team, it ensures that through behavioural modelling, they lead the growth of excellence by example.
Managing and coordinating multiple Communities of Practice
Communities of Practice should be aligned to the strategy of the wider organisation and this means someone needs to help align them.
A Capability Lead, or Capability Manager, helps align Communities of Practice. It is, though, just another agile team.
Senior managers and executive
With every team in the model now an agile team, it’s time to turn to the executive.
As an Agile Team, executive work on strategic themes, make large-scale economic decisions about the agency’s portfolio of work, utilising patterns such as Kenny Rubin’s Economically Sensible Scrum, a portfolio Kanban, or even patterns from the Scaled Agile Framework (SAFe).
Conclusions
The emergence of conferences like Business Agility is testament to agile’s universality. It’s no longer “just a software thing”. How we introduce agility to create high-performing, successful teams across organisations will be met with the same issues as we had with software teams. Borrowing learnings and adapting them in simple ways to reduce the complexity of matrix management and project over product focus, should be where we start.
