Experiences inside a team of coaches

During the last years, big companies are starting to adopt agile methodologies. Apart from those recent companies that have had an awesome growth, where being agile was part of their DNA, many more traditional companies have realized they need to have more effective ways of creating products in a fast changing environment like the current one.

Since doing agile is not enough to being agile, the adoption is being done not only at team level. It is fairly clear that agile is not just "IT stuff for the development teams". Instead, it requires having on board those that set the vision and the goals, those who depict the roadmap and those who take care of the overall architecture, those who have the understanding of the users' needs and those who create features. They all have to be involved, not only to be part of the process to create successful products, but, more important, to be part of the change in the culture of the company.

"On the Red Eagle ferry from the Isle of Wight to Southampton, passing the Queen Elizabeth" by Paul Smith is licensed under CC BY 2.0.

New culture requires new habits. For these new habits to emerge, most organizations embarked on this transformation process rely on a team to identify the pain points and collaborate to make this change real. The team can be external, internal or hybrid, this is not relevant. The important point is that this team must be empowered to do whatever is needed to have an effective organizational change and that at the end of the transformation the organization must have all the capabilities and knowledge to continue the journey with no external help.

With this introductory article, I want to start a series of posts where I will try to share the experience that I have had as a member of one coaching team. We had several iterations around how we worked after inspecting and adapting our process. I will talk about the transformation backlog we managed, our ceremonies, leading by example, dysfunctionalities, our values, the roles and the boards we created to visualize the information.

We had a lot of learning during this process and this is what I want to share. It is clear that every organization has its own culture and a process like this happens in a specific context. This makes almost impossible to have recipes or, even, best practices. However, learning can be obtained always.

Only one product owner?

According to the Scrum guide, the Product Owner is responsible for maximizing the value of the product and the work of the Development Team. This involves several tasks that are not to be done only by her, although she remains accountable. In addition, the guide stress that the Product Owner is one person, not a committee. This makes it easier when taking decisions that can affect different people's interests. Until now, nothing new. Then, why this title for this post? Let's provide some context.

Some weeks ago I attended a retrospective of a team that had an amount of problems. This time, instead of watching them from the back of the room I decided to spend 10 minutes at the beginning in order to revisit some core principles that were completely missing. I started with a question: why are we here? What is our goal in our day to day routine? And one of the team members answered: we are here to code.

This, let's say, innocent answer provided a lot of insight about what was going on in the team and made me think about the relationship that team members should have with their product. Teams that simply code what their product owners ask for in the user stories do not feel real ownership of their products. They just receive requests and process them, forgetting somehow that we value customer collaboration over contract negotiation. In situations like this, there exists a barrier between the product owner and the development team. The do not work as a single team, but as the customer and the provider. And, obviously, this affects seriously to the product and to the team.

This disfunctionality must be addressed by getting the team members more involved in the product they are building, more connected to it, more interested in its impact on the market. What would happen if this product were their product? I know many developers that have their personal projects, just for fun or as the starting point for a future startup. And they all speak passionately about them. They care about every single detail. So, what if we make them also owners of the products they are building in our companies?

At first sight this seems to be against the one person, not a committee statement. But this is not the point. The role of the product owner remains. There must be someone to drive the vehicle, to take the appropriate decisions and to be accountable for them. But she should not do this alone. The team members must have voice in the design of the product. And not only from a technical prospective. It's their product too. They need to know the problems they are solving to the users. They must have empathy with their users, feel their pains and enjoy their satisfactions. Because once they share these concerns with the users, they will be motivated to address them. And they will consider them when creating new features. The product is not the product owner's toy anymore. It becomes the team's product.

Forerunners of the All Blacks. Christchurch, New Zealand: Canterbury University Press.

And, how can we provide this ownership to team members? Just by involving them in the conversations where the users' needs are discussed and solutions are proposed. Jeff Patton's user story mapping workshops [1] are a perfect example. The user story maps should not be created just by the product owner. They should be the result of  a workshop where to have open discussions about the goals we have, the users we want to reach and the features we plan to create for them. Also, upcoming sessions, such as backlog refinements or the reviews at the end of every sprint need to consider all the team members. This way, we will have better products and more cohesive teams. And team members will not be just coders anymore. Coding will be part of their skillset, but not their only contribution.

References:

[1] Jeff Patton and Peter Economy. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly Media, Inc.