Currently I'm writing a series of blog posts about the retrospective I facilitated during Scrum Day Europe. I'll describe the strength of Scrum, experienced frustrations, small improvements and also what should be the focus the upcoming years. For the latter the participants suggested Scrum should focus on creating value-driven organizations. While doing some research on this idea I stumbled upon an old blog post I wrote two years ago: '6 Best Practices to Kick Start Your Scrum Team'. The idea was to copy a small part of this article but I ended up rewriting the entire blog post. The result is what you're currently reading. After this blog post I'll continu the series based on the Scrum Day Europe retrospective.
The purpose of Scrum is to create ‘done’, usable, and potentially releasable increments. Increments that deliver value to customers each iteration. Increments that delight the customer.
A truly value-driven organization also embraces value-driven contracts. These are contracts that have a foundation build on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adapting new insights and processing gained knowledge. It encourages acting on necessary changes and lessons learned. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset.
In reality however, agreeing upon an Agile, value-driven contract is difficult. When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract…
The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore it lacks a proven foundation of trust. The customer wants guarantees around budget, time, quality and scope. A decent change control process is lacking. After some tough negotiations the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A suboptimal product will be the result and the relationship and trust is damaged deeply.
To answer these questions I'll share some best practices. Mainly written from my experience working for a web agency as a supplier, completed with fulfilled Prowareness engagements. This is also the perspective I use. The customer is an external client asking support for a software development project.
Often the customer has an idea about the product and it's possibilities but a Product Backlog is still missing. A good practice is to organise a workshop with the customer and the supplier’s Development Team and letting them create the Product Backlog together. Even before setting up the contract. Ideally you also create the product vision to ensure mutual understanding. By creating the product vision and Product Backlog together the customer and supplier really get to know each other. More important: the customer meets the actual Development Team. They are the ones who are going to realise his dream. They are the ones he needs to trust.
After creating the Product Backlog together it's also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions & questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations.
When the Product Backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. In the same session, facilitate the stakeholders to discuss and determine the business value for every Product Backlog Item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner.
After estimating the implementation effort (done by the Development Team) and determining the business value (done by the stakeholders) the following matrix will appear. This offers great insights like:
When the implementation effort and business value is determined for every Product Backlog Item, it's time to detect the dependencies. Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders. This offers insights like:
Even when a customer has a huge budget for his project, first agree upon doing only one Sprint. After you've created and estimated the product vision and Product Backlog together, only do the first Sprint with the goal of delivering the first 'done', valuable and potentially releasable increment. Perform a Sprint Review and Sprint Retrospective and decide if there's enough mutual trust to start another Sprint.
Invite the customer to all the Scrum events. Let the customer experience how the Daily Scrum is done, let them experience the discussions during the Sprint Planning and share all the lessons learned during the Sprint Review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration.
Fixed Scrum Teams that have been working together for a longer period, have experienced up's & down's and know there velocity are worth gold. A common pitfall is to separate this 'golden team' when a new project arrives. Don't do this. Keep the team together at all costs. The customers gets the entire team, including tester, analist, designer, Scrum Master, developers etc.
When working with fixed teams that know their velocity, it's also easier to sell sprints for this team. Of course velocity is something for the team, will take 3 -5 Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of, can estimate a Product Backlog and give a range of how much Sprints the realisation will probably take, for example: between 5 - 7 Sprints.
Because the team is fixed they also know what the costs per sprint are, for example 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- During every Sprint Review, the Scrum Team and stakeholders can discuss the desired features that should be developed the upcoming Sprint. They can discuss how much value the will get taking the cost per Sprint into account. By selling Sprints the advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints.
In the end, it's all about trust. Creating the product vision & Product Backlog together, estimating the Backlog, determining the business value and dependencies, starting small and inviting the customer to the Scrum sessions are all practices to build this necessary foundation of trust. When there's a foundation of trust it also becomes easier to sell the entire Scrum Team and sell Sprints with a focus on business value. And of course, quickly delivering valuable, working software is the ultimate way to gain trust.
When the described examples are applied more often within organizations, the possibility of truly becoming a value-driven organization also increases. My hope for the upcoming years is that organizations that use Scrum, also use contracts that respect the Agile mindset and start new Scrum projects with a focus true collaboration.
What are best practices for Agile contracts or starting a new Scrum project that worked for you? Would love to know your point of view!
Customer Collaboration over Contract Negotiation
The purpose of Scrum is to create ‘done’, usable, and potentially releasable increments. Increments that deliver value to customers each iteration. Increments that delight the customer.
A truly value-driven organization also embraces value-driven contracts. These are contracts that have a foundation build on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adapting new insights and processing gained knowledge. It encourages acting on necessary changes and lessons learned. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset.
In reality however, agreeing upon an Agile, value-driven contract is difficult. When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract…
The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore it lacks a proven foundation of trust. The customer wants guarantees around budget, time, quality and scope. A decent change control process is lacking. After some tough negotiations the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A suboptimal product will be the result and the relationship and trust is damaged deeply.
But how to gain trust when you haven’t worked together before?
How to start a new Scrum project and setup a contract that focuses on outcome instead of output?
To answer these questions I'll share some best practices. Mainly written from my experience working for a web agency as a supplier, completed with fulfilled Prowareness engagements. This is also the perspective I use. The customer is an external client asking support for a software development project.
8 Best Practices to Start a Scrum Project
1. Create the Product Vision & Product Backlog Together
Often the customer has an idea about the product and it's possibilities but a Product Backlog is still missing. A good practice is to organise a workshop with the customer and the supplier’s Development Team and letting them create the Product Backlog together. Even before setting up the contract. Ideally you also create the product vision to ensure mutual understanding. By creating the product vision and Product Backlog together the customer and supplier really get to know each other. More important: the customer meets the actual Development Team. They are the ones who are going to realise his dream. They are the ones he needs to trust.
2. Estimate the Implementation Effort of the Product Backlog Together
After creating the Product Backlog together it's also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions & questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations.
3. Determine the Business Value of the Product Backlog Together
When the Product Backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. In the same session, facilitate the stakeholders to discuss and determine the business value for every Product Backlog Item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner.
After estimating the implementation effort (done by the Development Team) and determining the business value (done by the stakeholders) the following matrix will appear. This offers great insights like:
- PBI D, E, F and G have a low implementation effort and lot's of business value. So start with these items first.
- PBI H and I will take quite some effort to implement and won't offer much business value. So do we really want this on the Product Backlog?
4. Clarify Dependencies Between Product Backlog Items
When the implementation effort and business value is determined for every Product Backlog Item, it's time to detect the dependencies. Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders. This offers insights like:
- PBI C is a bottleneck. Discuss this item in more detail to solve the dependencies.
- PBI J and K also have a dependency, so take this into account when ordering the Product Backlog
5. Start Small
Even when a customer has a huge budget for his project, first agree upon doing only one Sprint. After you've created and estimated the product vision and Product Backlog together, only do the first Sprint with the goal of delivering the first 'done', valuable and potentially releasable increment. Perform a Sprint Review and Sprint Retrospective and decide if there's enough mutual trust to start another Sprint.
6. Invite the Customer to the Scrum Events
Invite the customer to all the Scrum events. Let the customer experience how the Daily Scrum is done, let them experience the discussions during the Sprint Planning and share all the lessons learned during the Sprint Review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration.
7. Sell the Entire Scrum Team
Fixed Scrum Teams that have been working together for a longer period, have experienced up's & down's and know there velocity are worth gold. A common pitfall is to separate this 'golden team' when a new project arrives. Don't do this. Keep the team together at all costs. The customers gets the entire team, including tester, analist, designer, Scrum Master, developers etc.
8. Sell Sprints
When working with fixed teams that know their velocity, it's also easier to sell sprints for this team. Of course velocity is something for the team, will take 3 -5 Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of, can estimate a Product Backlog and give a range of how much Sprints the realisation will probably take, for example: between 5 - 7 Sprints.
Because the team is fixed they also know what the costs per sprint are, for example 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- During every Sprint Review, the Scrum Team and stakeholders can discuss the desired features that should be developed the upcoming Sprint. They can discuss how much value the will get taking the cost per Sprint into account. By selling Sprints the advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints.
What's Your Opinion?
In the end, it's all about trust. Creating the product vision & Product Backlog together, estimating the Backlog, determining the business value and dependencies, starting small and inviting the customer to the Scrum sessions are all practices to build this necessary foundation of trust. When there's a foundation of trust it also becomes easier to sell the entire Scrum Team and sell Sprints with a focus on business value. And of course, quickly delivering valuable, working software is the ultimate way to gain trust.
When the described examples are applied more often within organizations, the possibility of truly becoming a value-driven organization also increases. My hope for the upcoming years is that organizations that use Scrum, also use contracts that respect the Agile mindset and start new Scrum projects with a focus true collaboration.
What are best practices for Agile contracts or starting a new Scrum project that worked for you? Would love to know your point of view!