Agile and Project Operating Models

“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.

pic1

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.

techmgmgt

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

pic3

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.

pic4

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.

context-jusggling
Source: HubSpot

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 mangers for “people” recourses

People on teams will still:

  • Be torn as to who to serve
  • Often still be across multiple projects

pic5

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 through Scrum Masters
  • Managing through Product Owners
  • Communities of Practice
  • Senior managers and executives

Managing through Scrum Masters

Turning capability managers into Scrum Masters is another model. 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.

pic6

I’ve never really found this model to work successfully. In terms of behaviour, it has it’s 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)

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.

I understand that this is what happened with one of the first eXtreme Programming projects. It failed. 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.

pic0

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.

pic7

Spotify has two structures in their organisation, Guilds and Chapters.

  • Chapters – cutting across teams (Spotify call 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.

pic8

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.

pic9

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.

pic11

A Capability Lead, or Capability Manager, helps align Communities of Practice. It is, though, just another agile team.

pic12

Senior managers and executive

With every team in the model now an agile team, it’s time to turn to the executive.

pic13

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).

economically_sensible_scrum
Economically Sensible Scrum

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.

 

 

 

 

 

 

 

 

Advertisements

One Comment

Comments are closed.