This is probably one of the most important texts I will write in this series of articles. It is also one of the longest. But bear with me, I think it is worth the read.
Taken one by one, we humans are among the weakest creatures on the planet. We lack for the most part fur, sharp teeth, big muscles, and fast legs. And it takes us almost 26 years from birth until we can be considered adults.
But the human collective, together, has been able to conquer the moon. And put the rest of planet Earth under us.
So individually, we are weak. Together we are strong.
And this is the reason why we apply organizational models at all. Any kind of big work needs to be done by us, not by you, not by me. We need to organize.
Industrialism of the 1900s saw the advent of the ideas put forward by Friedrich Taylor: Some people design and plan work, others just do the work. The conveyor belt and other attributes of the modern factory are built on these ways of thinking.
The efficiency of the Tayloristic model is undisputed. Under certain circumstances. What circumstances? When does Taylorism work?
From this we can conclude that Tayloristic models of organizing work are very ill-suited for the development and maintenance of complex services:
This has been understood for a long time. In the 1960s, with the advent of computers and complex systems development, people quickly figured out that complex systems need to be developed by cross-functional teams in small increments.
They developed a solution a little bit, inspected the result, gathered the insights gained, planned for the next little bit, and developed that. Again and again. We wouldn't have succeeded to go to the moon if we had abandoned incremental and iterative development.
But for several years, we did just that: abandoned incremental and iterative development. In the late 1980s, people started to experiment with project models based on pre-planned activities. Models that shunned the very idea of iterative understanding of both a problem and its solution. Models that under the hood relied very much on many of the assumptions made by Taylor in the late 1800s and early 1900s.
The result was not very successful. The models didn't work very well back then, and they still don't work well for systems development. Few digital development projects can be regarded as successes using this approach.
So what the early proponents of the methods later known as "the agile methods" did in the 1990s was basically to return to the old proven model of incremental and iterative development again.
Models built on the fact that development of complex systems is a matter of gaining insights as they unfold. Step by step.
The two agile methods from the 1990s that gained early traction and widespread adoption were Scrum and Extreme Programming (XP). Both Scrum and XP are built on the following assumptions:
From this comes all the agile practices based on self-organization, teamwork, and day-to-day collaboration between different experts. As the Agile Manifesto with its principles puts it:
An extremely successful model when it works. And still: we seldom make it work.
Why? Our failure can to a large extent be explained by how we have structured our organizations.
Taylor had a French admirer: Henri Fayol. Fayol created organizational structures based on functional specializations: if you had a skill, you were supposed to work together with others who had the same skill. And you did it in a department led by a person who presumably was more knowledgeable about your and your colleagues' work than you were yourselves. A person responsible for the outcome of what you were doing.
This hierarchical pyramid setup makes cross-functional endeavors hard. The model doesn't readily support people with different specialties who need to work closely together to create a change they can't make without each other. The model supports the preservation of the organization and its services. It doesn't support changes very well.
So pyramid organizations tried to enable this cross-functional collaboration capability to change anyway, by using project models to coordinate it all. But the projects were only temporary and are (as we saw above) riddled with other problems.
Sometimes the pyramid organization tries to reorganize itself into new kinds of organizational silos. But the new silos block collaboration and change just as much as the old ones do.
So many organizations have adopted a fictional "buyer/supplier" model for organizing the development of digital services. One part of the organization requires a change in a digital service. They "order" the change from the department where the development capacity sits.
But that setup always generates a host of problems:
Scrum has a way of dealing with this. The framework requires the organzation to come up with one clear designated "product owner", responsible for the integrity of the service throughout its whole life-cycle. One person responsible for answering these and other questions:
In the chaos created by the "buyer/supplier" model, the Product Owner has the responsibility to bring order by unifying all the different "buyer" perspectives. Being a product guardian between the team of service developers and the rest of the organization. A doorman arranging the queue outside the developer's party, with the authority to say who can attend and who needs to leave.
Early Scrum became in reality very much a defense around the development department. More so than a collaboration tool between different departments. And many organizations start their agile journey in a situation that looks very similar to that. Even today, in 2020.
In people's minds, "the Team" was for a long time (and this is reflected in early texts on Scrum) the group of developers. The development team played the role of "the supplier". The Product Owner took the role of the single "buyer", standing close to the team but not being a part of it.
But bringing order to a chaotic "buyer/supplier" model by having one single individual act as the "buyer", can only improve the situation marginally. One of the ingredients of the agile magic is the amalgamation of business perspectives and technical perspectives. That requires the daily collaboration between people bringing these different perspectives to the table.
So gradually the language of the Scrum Guide has been more and more specific about this unity of views and people. The Scrum Team was in many versions of the guide said to be made up of both the Development Team and the Product Owner (and the Scrum Master but let's forget them for a while).
And finally, in this version, they abandoned the notion of a separate development team. From now on, the Scrum Team is said to consist of people. People with different responsibilities and capabilities, but they are all in the same team.
The self-managed Scrum Team with all the authority to develop the product as it sees fit. The Product Owner is after all a team member, and the Product Owner had this authority already, in all the earlier versions of the Scrum Guide.
So with the Product Owner on board, the team has all it needs to be self-managed (according to Scrum).
So the new Scrum Guide (2020) paints the picture of a self-sufficient team of developers, that together with someone taking on the product owner responsibility together assume full life-cycle responsibility for a service. They explore what needs to be met, what can be changed for the better in the servie, and they also do it, in small steps.
That already implies that the team isn't self-sufficient at all.
Self-managed doesn't imply self-sufficient. The self-managed team needs to manage itself to become experts at improving the ability to understand and collaborate with other people. Which is totally in line with the Agile Manifesto:
The Scrum Guide can be deceptive here: This kind of collaboration is implied by Scrum, but Scrum is at places vague or silent about it.
What has the Scrum Guide to offer in terms of a Scrum Team's points of contact with the outer world?
First of all, we have the Product Owner. The Product Owner should be able to represent every important aspect of a service, including key stakeholder views, customer and user insights, and so on.
The Guide doesn't tell us how this can happen, but it is obvious that Product Owners need to have many conversations with many different people from many different places. From within and outside of the organization.
Another point of contact that is explicitly mentioned in the Guide is the Sprint Review. Here, the team together with key stakeholders look at the changes made by the team during the sprint and get ideas about what to do next.
It doesn't look like much, and even these two simple things are often forgotten or are misused. The Product Owner might not be able to talk to everyone. Or people try to act within the old "buyer/supplier" paradigm and treat the Product Owner as a shopkeeper instead of a partner and co-creator.
Or it could even be the Product Owner who sadly enough treats the rest of the team as "suppliers" instead of colleagues.
It is also very common to forget to invite key stakeholders to the sprint reviews. Or forget to inform them about what is expected of them.
If we want to be able to create fantastic services pretty quickly, we need to collaborate. We need to mix our different views, and we need to add all our insights. People from different departments need to work together daily.
And with their deep knowledge about how to make changes in the services, it is the members of the Scrum team who need to invite the others.
The last one is especially important. As a Product Owner, you are not supposed to be just a mediator, a vessel of information. Make other people's conversations happen! Enable the conversations, don't try to have them yourself.
You can, if you think it is helpful, follow these lines of thought even further. For example:
If you want to get some help around extending the collaboration across the organization, just let me know!
Be it through workshops, trainings, self-study material, me being present coaching you, or something else.Did you give trainings as well?