Agile for PMs – bring the work to the team
The “Agile for PMs” articles are written for experienced project managers who are interested in exploring how Agile development differs from classical project management.
In these articles, “Agile” is generally capitalised (and sometimes used as shorthand for “Agile development). The Agile Manifesto is described in more detail in other Plays on this site.
As we saw in AgileProjects, Agile development starts with the team rather than creating a team around the goal. And we saw that Agile developments have more in common with Programmes than projects, including tools and approaches to address emergent learning and change.
Programme: A temporary flexible organization … (AgileTeams) … created to coordinate, direct and oversee … (AgilePlanning) (AgileEstimates) (AgileRisk) … to deliver the organization’s objectives (AgileProjects) (AgileComplex).
Managing successful Programmes
Teams and Agile
The “Managing Successful Programmes” standard emphasises that a Programme effectively functions as a “temporary flexible organization”. Agile development needs to be viewed in a very similar way with the team as an semi-autonomous organization at its heart.
The origins of Agile development can be traced back to an influential article by Takeuchi and Nonaka in the Harvard Business Review called “The New New Product Development Game” (the double “New” is not a typographic error). This is an important reference throughout the Agile Plays site, and a summary here may be helpful. The key reference for Agile development is the Agile Manifesto, but this article is one which influenced the Manifesto (and especially the creation of the Scrum framework).
Takeuchi and Nonaka proposed a new, team-based, way of working. Teams with a high level of autonomy, free to set their own direction. Diverse skills that shared ideas across all the functions of the business, rather than having sequential specialisations. Learning and adapting to the changing environment.
In the article, the authors identify three key factors which are needed to make the team successful. Although some of the language may have changed, these are core principles for Agile teams.
A group possesses a self-organizing capability when it exhibits three conditions: autonomy, self-transcendence, and cross-fertilization.
“The New New Product Development Game” – Takeuchi and Nonaka
Cross-fertilization
Takeuchi and Nonaka refer to the power of a project team having a wide range of skills. They referred to this as “cross-fertilization” although it is typically now referred to as “cross-functional” teams. This differs from the traditional approach of functional groups organised by skills being assigned independent tasks within the project.
There are several strong reasons for building cross-functional teams. The most obvious is that the team has the skills to solve problems. This reduces the level of dependency on people outside the team. That in turn increases the team’s autonomy because they control what they need. It also reduces delays and handoffs which Lean highlights are key areas of waste.
There are also more subtle impacts to a cross-functional team. By building the various roles into a single team we ensure cross-functional conversations. Within a single team these tend to be constructive and to bring together disparate viewpoints.
Diverse viewpoints are better listened to because they are within the same team. The wider viewpoints widen the shared objectives. And this builds team identity and increases team unity.
You then start thinking in terms of what’s best or second best for the group at large and not only about where you stand.
“The New New Product Development Game” – Takeuchi and Nonaka
Self transcendence
A key factor the authors highlighted is the team challenging themselves. They set their own targets and keep striving to make themselves better. They manage not only how they work but how they improve. It is the ability to develop in unexpected ways which leads to greater improvement.
In the 1950s McGregor’s Theory X and Y looked at the two viewpoints about innate behaviour. Were individuals inherently lazy and reward-oriented or self-motivated? In Scientific Management, the assumption is made that workers are inherently lazy.
To build successful self-managing teams we need to take the other view and trust the team. They need to achieve “Self-transcendence” where they self-manage not only their own work but also their improvement. This can be through owning retrospectives, learning, training and development.
Autonomy
Team autonomy is perhaps the most obvious factor in self-managing teams. Allowing teams autonomy keeps them in a tight feedback loop on decision making.
“The New New Product Development Game” suggests a high level of autonomy close to a business unit or microenterprise. For an article written in the 1980s, this is a very modern viewpoint on business agility (beyond most software teams). Haier, who restructured around microenterprises, put it like this:
In the past, employees waited to hear from the boss; now, they listen to the customer
Zhang Ruiminm, CEO Haier
Self-managing teams
These three factors add together to create “self-managing” teams. Takeuchi and Nonaka use “self-organizing”. The Agile Principles refer to “self-organizing” teams. The Scrum Guide used “self-organizing” until 2020 and replaced this with “self-managing”. As is usual in Agile terms, there is no clear agreed naming here.
The most common understanding is that self-organising means “decides how to perform the assigned work” while self-managing means “decides how to deliver the required objectives“. The difference is subtle, with self-managing suggesting a little more autonomy, and I prefer to use “self-managing”.
Self-managing teams have far lower levels of delays and handoffs as they minimise dependencies and feedback loops in the organisation. In a slow-moving environment, we can listen to the customer, escalate the requests through layers of management and wait weeks for a decision to come to the team. For the modern technology world, we rely on rapid feedback.
In a complex environment the situation is worse. You cannot wholly predict how your actions will affect the outcome. Central to Agile development is the ability to respond and then adjust your response according to the effect. Feedback becomes even more tightly coupled.
Decision making
For an Agile approach to teams, we need to rethink traditional approaches to management. Escalating all decisions up a hierarchy is just too slow an approach. Worse still, managers are not typically the people with the most accurate, current data. There is not only a delay in the response, but there is a loss of data which is being used for the decision. The local teams understand the local situation while abstracted management are unlikely to do so.
Increasingly, successful technology organizations are moving to more distributed management systems (see “Management as a Service”). The main characteristic of these is the use of lowest viable level decision making. We aim to make decisions quickly and efficiently. This is done by taking the decisions at the point as close as is possible to the situation being decided. This principle drives many of the approaches used in Agile development.
Build projects around motivated individuals.
Principles behind the Agile Manifesto
Give them the environment and support they need,
and trust them to get the job done.
Self-managing teams can be a challenge to traditional management structures.
- We want to build team autonomy. This conflicts with Scientific Management “command and control” approaches and managers trained in these methods.
- We want the teams to be cross-functional. This conflicts with traditional skill-based functional silos and organizations structured in this way.
- We want them to be self-managing and strive for improvement. And this conflicts with traditional management or performance and reward.
- Finally we need them to work together as a team without fragmenting.
It is no great surprise that building these teams is a challenge in any organization.
Good practices
A self-managing team is effective, but requires us to rethink some areas of traditional management. As a leader, you should consider how to implement some of these changes
- With decision making being more distributed, teams and managers must keep better records such as decision logs to record the key decisions being made.
- Team decisions will also need to be broadcast to managers and to other teams so you will need to work out a good system for this.
- You need to step back from decision making and avoid over-asserting your views. You will need to encourage independent decision-making among team members.
- Teams need to be empowered to make decisions. You will need to coach them in which decisions are appropriate and which should be escalated. You will need to ensure a culture of Psychological Safety where they feel safe to make decisions.
- In order to make decisions quickly at the team level, the team need to be kept informed. This means that you will need to communicate well and give enough contextual information to the team.
The biggest change however needs to be in reviewing your own behaviour, ensuring a move away from the ideas of Scientific Management towards a less-autocratic, less-egotistical Agile management style.
Leave a Reply