Starting with Scrum:  1 - Starting with a New Product

Welcome to the 'Starting with Scrum' series.

Want to read the full Series? See here for the link to: Article 2, Article 3, Article 4

Where to start with Scrum? Obviously, you need a team. And a product. And customers for whom you can deliver value.

For the sake of argument, let’s assume we have an ambitious, self-organizing team with a relatively mature understanding of Scrum. They have been working together for a while and form a well-oiled machine. Think “Performing” in Tuckman’s model.

The team has been asked to work on a new product. The team has been chosen because they have all the necessary skills for this product. The product has been explored in an initial viability study, which has resulted in a product vision and a product strategy.

Source: leanstack. The Lean Canvas is a very effective way of facilitating an Agile approach. It focuses on the essentials: things like customer value, business value, costs and risks, and helps avoid extensive requirements and planning documents . In other words,  the usual documentation-heavy furnishings of a non-Agile approach.

Everything is in place and the decision has been made that this is a viable enterprise. Now it is time to get started.

So how do we start? What is the next step?

The Product Goal

I think the best way of getting started is by determining the Product Goal. This makes sense because the Product Goal lies at the beginning of everything. It is necessary to start creating the Product Backlog, which we need in order to go into Sprint Planning and so on.

The Product Goal gives every conversation a razor-sharp focus. It is the purpose that keeps everyone aligned, and is the most important tool for Product Owners in their interactions with stakeholders.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
– Scrum Guide –

It is important to realize that a Product Goal is not just a simple one-liner, but an evolving goal of everything the vision of the product represents. The one-liner lies at the heart of the Product Goal, it is the elevator pitch that we use to draw people’s attention. But once we have that, we need to expand the Product Goal with all the details that are relevant for its realisation. Details such as customer profiles, metrics and the infrastructure requirements.

Another important aspect of the Product Goal is the focus on what we are trying to achieve and why it matters, leaving how the goal will be achieved to the Scrum Team. This allows the Team to take ownership of the approach, ensuring an Agile approach.

Of course, as is typical in Agile, this is probably never clear-cut, and grey areas do exist, but there are ways to include these without threatening the Agile approach. The one I think works best is by incorporating them as constraints.

Product Goal Workshop

To determine the Product Goal, my favoured approach is to organise a workshop to which I invite two parties:

1. Those involved in the initial study for the product. I’ll call these stakeholders.
2. The Scrum team.

The goal of the workshop is twofold. On the one hand, it allows the first party to transfer their vision of the product, the goal they are trying to achieve, to the Scrum Team. Material from the viability study is very helpful in this process.

On the other hand, it allows the Scrum Team to translate this vision from a more technical perspective. Most important in this process is giving the Scrum Team plenty of room to ask questions and discuss aspects of the goal. It is their job to challenge assumptions and consider the technical viability of the suggested solutions.

It is in the synergy of these two groups – the idealists and the realisers – that the Product Goal is born. Without the team, the idea is just that, a possibility, a dream. With the team joining in, we get a notion of how the dream can become reality.

The session will usually take between 1 and 2 hours.

As the Scrum Master, I will usually be the one at the whiteboard summarising details. The advantage of this is three-fold:

• First of all, it leaves those present to focus on the discussion;
• Second, it provides a running summary of the conversations taking place. It confirms understanding because it provides something for those present to correct and improve upon;
• Third, working with a single whiteboard and favouring keywords keeps everyone focused on a higher level of detail.

It is such a rewarding process for all those involved, seeing the fruits of the discussions, a mutual understanding taking shape in real-time in front of you. People will usually get really enthusiastic, stand up and take over. By the end of the meeting, I will probably be sitting on the sidelines. And you can tell when the meeting is finished because discussions will wind down, as people sit back and look proudly at their work.

The benefit of this approach to me is invaluable. As those present witness the Scrum Team shaping dreams into reality, so to speak, demonstrating their level of understanding and expertise, it creates a lot of trust in the team. Moreover, by involving the complete Scrum Team in the process, we create a sense of ownership among the entire team. In fact, with this one meeting we essentially work on the three pillars of motivation as described by Daniel Pink:

• Purpose: The Product Goal, as it forms itself in the collective intelligence of the team;
• Autonomy: By giving the Scrum Team room to translate the Product Goal into their own definition of it, the team takes control of it and makes it their own;
• and Mastery: During the process of translation, the Scrum Team automatically develops an understanding of what needs to be done, thereby gaining confidence.

In his book Drive, Daniel Pink discusses how motivation depends on three factors, purpose, autonomy and mastery.

Conclusion

Notice how this approach honors the values of the Agile Manifesto:

Individuals and interactions over processes and tools: People are communicating and collaborating with no attention to the process itself. The process is so natural that it disappears into the background. Tools (a whiteboard instead of a Jira board) are unobtrusive and serve the interactions.

Working software over comprehensive documentation: This one is a bit abstract, but if we consider information management as an integral part of a developer’s job, what we have is people working together to manage complex information in a clear and efficient manner, avoiding huge documentation with endless requirements.

Customer collaboration over contract negotiation: There is absolutely nothing resembling a contract in the process, just a building of trust and a collaboration between the two parties to determine what needs to happen.

Responding to change over following a plan: Discussion is high level and everyone understands that at this level there is a lot of uncertainty. Uncertainty is a given and the attitude is one of exploration.

But most of all, what I love about this approach is the way it seems so natural to all involved. It is efficient and effective, but at no time does it feel like that is the purpose. That is the beauty of Agile done right: it involves shedding choking procedures, expectations and controls and just simply doing what is needed on a basis of trust, respect and an understanding that we are all highly motivated to get this thing done!

The next article in this series is about translating the Product Goal into a Product Backlog. You can read the second the article here.