Regularly I read Barry Overeem’s notes because he gives practical advice about Scrum, always in a concise and understandable way. In this recently updated article, he demonstrates 8 practices to set up at the very beginning of a Scrum project: before and during Sprint #1. If you find his article too long to read, here are some notes to sum it up.
Although they are relevant insights to set up a successful Scrum Team, I bring some comments (framed with <NC></NC> tags) because in my opinion this is too close to an ideal world: a majority of organisations are not designed to enable such a way of working.
The purpose of Scrum is to create ‘done’, usable, and potentially releasable increments. Increments that deliver value to customers each iteration. A truly value-driven organization also embraces value-driven contracts. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset.
The difficulty with contracts is that it’s all about trust. But how to gain trust when you haven’t worked together before?
Create the Product Vision and Product Backlog Together
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. 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.
<NC> I have been working with ‘Scrum Teams’ that do not follow a vision or a roadmap. Why? Because they do not even work on a ‘product’. Some organisations have simply applied Scrum elements (artefacts, events, roles) to a traditional ‘project’ (team). Consequently, the Product Owner key role is usually endorsed like a former Project Manager role, or it is devoted to some business people outside (and far from) the team. But these people won’t think about vision, coherence and roadmap: they will express their urgent needs on-the-fly directly to the first available developer they find.</NC>
Estimate the Implementation Effort of the Product Backlog Together
The advantage is the customer hears all the discussions and questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations.
Determine the Business Value of the Product Backlog Together
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. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner.
- 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?
Clarify Dependencies Between Product Backlog Items
Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders.
<NC> Here it is about dependencies that are ‘internals’ and so that can be fully handled by the team because they work in an end-to-end mode / process. Issues and delays pop up when facing dependencies with external teams, because the ‘product’ is split through several teams. </NC>
Start Small
Even when a customer has a huge budget for his project, first agree upon doing only one 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 the Scrum Events
Invite the customer to all the Scrum events. Most important of course is to gather feedback about the delivered product and evaluate the collaboration.
<NC> Here you might face some resistance from business people and/or customers: they do not have time to attend Scrum Ceremonies, and a big challenge is to convince them to show up. But without support from their top management, it can be tough. </NC>
Sell the Entire Scrum Team
Fixed Scrum Teams that have been working together for a longer period, have experienced up’s and down’s and know their 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.
<NC> Teams that remain stable on the long-term is very rare in the current IT industry. It is very hard to maintain a team with the exact same members. Reasons are multiple: companies suffer a high employees turnover, many different projects run in parallel and require high flexibility of people availability so teams are built, unbuilt and built again very often, or people want to learn more and to embrace a new challenge.</NC>
Sell Sprints
[…] 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,-.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.