A 2-day London SCRUM course in 4 minutes (and 14 points)
Misconceptions about SCRUM are many. Some people love it. Some people hate it. I have personally always struggled to distinguish between its theoretical foundations and its many implementations.
After almost one year of hands-on experience in product management, in June I have been so lucky to attend the CSPO (Certified SCRUM Product Owner) course held by Roman Pichler in London.
During the 2-day workshop I have learned some lessons that will forever shape my path towards product. And I am going to share them with you.
1. SCRUM is not for every company
- SCRUM assumes trust. It implies delegation of the decision-making process to the team. Hence it is not for every company.
- SCRUM assumes failure acceptance. It states that main learning comes from failure. This risk-taking attitude it is not for every company.
2. SCRUM is not for every product stage
SCRUM is ideal for early stages, when uncertainty is high. Indeed, it protects the team through time-boxed sprints and defined goals. Other agile frameworks, like Kanban, are better suited for later stages, when the focus is on ongoing improvements and the business requests are more predictable.
3. SCRUM does not tell you what to build
SCRUM does not help you in product discovery. SCRUM is an organisational framework for software development in conditions of high uncertainty. It helps you in going from a backlog to a working product. but does not say anything on how to translate an initial idea in a groomed backlog.
4. A product must produce value for both the users and the business
- A product is a set of capabilities that provides value for the users and the business by its own.
- A feature is a product capability a user can interact with.
- A component is an architecture building block.
Product, features and components can be used as a scaling option for POs (see point 6. below).
5. A true PO owns 3 levels of product responsibilities
- A true PO owns the product vision (= ultimate goal).
- A true PO owns the product strategy (= paths towards the vision). The main tool used for this is the product roadmap.
- A true PO owns the product tactics (= steps of the strategic path). The main tool used for this is the product backlog.
These three levels can be used as a scaling option for POs (see point 6. below).
6. No scaling option for POs is perfect
In the early product stages having only one person manages the product has strong benefits, since it makes the decision-making process quicker. As the product matures, multiple scaling options can be chosen, such us:
- Feature vs component owners: the PO manages both the strategic and the tactical level, retaining product backlog and prioritisation decisions. The feature and component prioritisation decisions are instead made by feature and component owners, which manage the team.
- Strategic PO vs tactical PO: the former manages the strategic level (strategy, roadmap, stakeholder, etc.), while the latter manages the tactical level (backlog, stories, team, etc.). Close collaboration is essential to avoid a disconnect between the tactical and strategic level (and especially that tactic feed back into strategy).
7. A growth mindset is a key PO skill
A PO role is interdisciplinary by nature. A PO needs to understand business, tech and UX. And then mature vertical expertise in the product specific fields. Hence, how fast a PO learn is then a lot more important than how much you know he begins with [in my current project I had not only to learn about tech and UX, but also about Messenger marketing, Facebook APIs and user onboarding].
8. The development team is a self-organising entity
The PO goal is to manage the product, not the process or the team. These are responsibilities of the SCRUM master [I still struggle with this. In my current project we don’t have a SCRUM master, which means that managing the team dynamics is still on the PO → me].
9. Top-down product planning reinforces bottom-down agile execution
The product roadmap is a key tool for product planning. It is true that a product developed in SCRUM should emerge from user feedback. However, having clear, top-down goals helps execution to be aligned with the product vision and with the business strategy, and addresses the need for accountability towards stakeholders.
10. Prioritisation criteria depend on the product stage
- In the early stages is better to prioritise by risk. Fail and learn fast reduces uncertainty and increase the chances of success.
- In the later stages is better to prioritise by cost/benefit. In this way the focus can shift on optimisation and effectiveness.
11. Product quality is implicit in the “Definition of done”
Traditional project management theory talks about 3 constrains (cost, time and scope). Sometimes quality is added to the list. Product quality is a property of the SCRUM process, intrinsic in the “Definition of done”. As long as the PO does not change the definition, he never compromises on quality (quality → increments are shippable = the software is working, tested and documented).
12. The product backlog is a tool to create transparency on outstanding work
The backlog is a tactical tool, whose items should be:
- Prioritized
- Groomed
- Emergent
- Detailed
- With no dependencies
13. The product backlog update requires new knowledge
The main goal of SCRUM is learning and reducing uncertainty. The backlog should only be updated if the PO has more evidence than before. New feedback should be incorporated in its items, which are defined as ready at the following conditions:
- Shared understanding
- Small
- Testable (= with acceptance criteria)
14. The 3C are the main components of a story
- A card: it is concise, small and easy to visualize (to foster collaboration).
- A conversation: it is a living artifact, co-created with the development team. Talking about it is a fundamental component of the story itself.
- The confirmation: it has acceptance criteria, so that they can be testable and marked as done.
As you can read, what I have learned is effectively not limited to SCRUM at all. It is much more. It is about to product, agility and leadership.
For me now SCRUM is not a one-size-fit-all concept. It is a dynamic framework, which needs to be adapted to each project’s specific needs. Indeed, to use Roman’s words:
“If in doubt, experiment”
Have a good journey,
— Livio
17/10/2018
P.S.: Why am I spending hours writing articles like this? Find out more in the post linked below (and clap, if you agree with 👇).
P.P.S.: this article is created out of my personal notes and of my own understanding of the content of Roman’s CSPO course.
