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.

It's not your product, it's your users

Recently I was involved in a user story mapping workshop with one team. They had done it in advance and asked me for advise to see if the work items they had identified were right or not. I am not an expert in their domain. However, as they were explaining their epics to me, I realized they had a very technical view of what they had to built. Their value stream was not the users', but the needed steps to create the infrastructure that would support several features they had identified as very important for the users.

In my experience, this is a common situation when preparing product backlogs, specially if technical people are involved in the process. The focus is not on what to build, but on how to build it. So, the question we need to bring immediately is: who are your users? In this case, the answer was a very concrete profile. Next question: can we bring them to the workshop? Fortunately, this was possible. And this is what we did.

The following day we asked the user to tell us one day in her life in relation to the process that the product under discussion was supposed to enhance. This was the starting point for a conversation with both business and technology that allowed to identify the actual needs of the user. Based on this, we started to build a new story mapping which, in this case, was a real user story mapping. Once finished, we already had a very valuable outome: the team became more conscious of what they were expected to build based on the fact that they are not supposed to create features, but to deliver value.

© dmason for openphoto.net

The main conclusion that I have from that session is the importance of opening your doors to those people that have the first hand information about the problem or need you want to address. It is very tempting, and I have done it plenty of times, to suppose everything about the user and start working according to those suppositions without validating them. Why don't we realize we should be humble enough to go and validate these assumptions? Are our users very simple beings that can be modelled easily? I don't know if the origins of these behaviors are in the waterfall model, where everyone is supposed to get inputs from the previous stage and generate outputs for the following state with no more help than extensive documentation. No matter the reason, it is time to stop doing this kind of niche work based on what we know. We need to do work based on we don't know. And this means involving those who have this information in order to start a joint journey whose end will be for sure the delivery of real value.