Agile teams need an Agile organization
Scaling, Culture and Agile Evolution – Part 1 Teams do not exist in a compartmentalized universe: they are part of an organization and are exposed…
Scaling, Culture and Agile Evolution – Part 1
Teams do not exist in a compartmentalized universe: they are part of an organization and are exposed to correspondingly strong influences from the organization. So if you think that working in a team is enough to make a lasting change in culture, you’re heading for a frustrating failure.
Learning as an understood goal of the organization
The descriptions of accelerated learning have a common silent premise: the organization as a whole understands the need for continuous learning.
This means that
- The task at all allows to provide increments
- Legacy issues and unnecessary complexity are understood as a problem to be addressed
- The team must have a certain stability
- Old habits of thought and other bad legacies are worked on regularly
- Team leaders need to understand how leadership, motivation, and team performance are related.
Task definition and the ability to deliver increments
Product Owners regularly find it difficult at first to structure tasks in such a way that the team has any chance at all of delivering value at the end of each sprint. Yet this is the interface that perhaps most effectively links the team’s work with its external perception: better, more regular, more reliable delivery at short intervals works both
- inwards – the team reviews its work and can quickly identify and eliminate deficits
- to the outside world – nothing is more capable of establishing trust in the work and thus keeping your back free. The agile way of working shows its positive effects and immunizes against control reflexes that the superior may have.
Legacy and unnecessary complexity
However, this is not always so easy to achieve: usually, one works on the basis of an existing code base, which is often too little structured, couples components too strongly and often does not even have a solid base of automated tests. Renewing such a code base is lengthy and costly.
When introducing an agile way of working, the team and the organization (specifically, the line managers) must be aware that a significant investment is required to achieve and sustain the benefits.
Team stability
Another misunderstanding is also often observed: a team does not always correspond to a project. If you try to assemble your own team for every new, perhaps small project, on the one hand you constantly have a different composition of “teams”, on the other hand this leads to the fact that each person typically has to work in many contexts: this is exactly not an environment in which organizational learning is favored.
Teams should be stable, long-term organizational units, while in many companies projects change and overlap. This turns the usual matrix organization on its head, in which the focus is on optimal “resource utilization”.
Thinking habits and other bad legacies
A whole host of procedures can be an obstacle to the team developing a common sense of purpose and direction: from the personality of an individual supervisor to incentives, career images, reward systems in a company.
There is one more fiction to mention: in many depictions of Scrum and other agile environments, the good team faces the evil outside world. The old Scrum image of the chicken and the pig is the best example of this.
But the team members’ expectations and behaviors reflect the same values that are generally lived in a company:
- Career and team responsibility are understood as a conflict
- Blaming is almost always the first reflex when something goes wrong
Therefore, introducing agility is not just a new process – it is the start of a profound change in work and collaboration, in expectations and goals – in short, in culture.