Scrum - The Art of the Possible
Writing is a good way for me to digest information, so in this post I am collecting important principles and practices of Scrum. Lastly I am listing questions that I have about Scrum and references for further reading.
If you can only do one thing, watch the video Agile Product Ownership in a Nutshell!
Below you see the city of trees that we built during our two sprints at a ScrumMaster training. Impressive, huh? :-)
ScrumMaster training
This week our team attended a 2 day training by Andrea Tomasini and Niels Verdonk of agile42, with the eventual goal to become a Certified ScrumMaster. After using Scrum with my teams for the better parts of 2 years, I thought I had a pretty good idea about how Agile and Scrum work. During this training I realized that there are many more things to learn.
I am collecting bullet points of what I found most interesting, as I don’t have further explanations for most of them. Maybe these notes can still be useful for others to start thinking about Agile and Scrum in new ways.
Principles
- Don’t focus on the practices. Understand the principles, so that you can adapt the practices as needed.
- Scrum is a vehicle for teams to practice empirical process control
- It aims for transparency, inspectability and adaptability.
- Software development is not a linear activity, especially when dealing with the uncertainties of building a new product. Trying to force the development into a linear process is therefore counterproductive.
- Empower the team to find a solution. Finding solutions is a creative activity for which you need to trust the team!
Practices
- The Scrum framework consists of
- 3 roles (product owner, scrum master, development team)
- 3 artifacts (product backlog, sprint backlog, burndown chart)
- 3 ceremonies (sprint planning, daily scrum, sprint review & retrospective)
- The ScrumMaster focuses on the efficiency of the team, not the usefulness of the product
- The backlog is the product of the continuous conversation between Scrum Team and stakeholders
- Items in the backlog have different granularity. Sometimes the granularity of the stories is expressed by different names like User Stories < Epics < Themes.
- Depending on the main focus of the story, sometimes we differentiate between
- Feature Stories
- Technical User Story
- Spike
- All stories should be as equal as possible in complexity
- The question “who is doing what” should always be answered as late as possible within a Scrum team
- Working on 6-10 stories per sprint tends to be a good sized 2 week sprint.
- A healthy backlog should be DEO
- Detailed appropriately
- Emergent (continuous / not planned)
- Ordered
- A user story needs to be integrated across the whole application layer, as it
- Forces the team to work together cross functionally.
- Prevents mocking of functionality.
- Identifies risks earlier
Questions
- In Scrum we want to get feedback fast, in order to learn and adapt fast as well. At the same time we don’t want to build prototypes but always build production ready quality. Isn’t that a contradiction?
- How to introduce shared responsibility in a team, while still getting a sense for the performance of an individual developer?
- Scrum aims to deliver the highest possible value in each iteration. Does this always have to be business value, or is e.g. learning considered valuable?
- Which type of project is Scrum not a good fit for?