Photo by Leon on Unsplash. This article is originally published on dev.to on 2 May 2021.
As I will be joining a company where Scrum seems prevalent, I decided to read a book called Learning Agile written by Andrew Stellman and Jennifer Greene. It's such a great book that given me a better idea of what it's like to be a part of a scrum team.
In this article, I'll summarise 20 things from the book that I found particularly useful and important for a complete newbie including myself.
1. Each role has a different perspective on user stories
There are many roles to form a Scrum team such as Product Owner, Scrum Master, Team lead, Lead developer, etc.
For developers, for instance, a user story is the functionality written in a simple and easy way to understand. We use user stories to break up and organise tasks. For the team lead, user stories are a tool to communicate with developers to help them figure out what should be done next.
The product owner, on the other hand, sees the list of user stories as values that will be delivered to the company. User stories are the tool to communicate with customers to validate what they are looking for.
2. Before diving into coding, have discussions to see user stories in the shoes of other roles
Because understanding of a user story can differ depending on the roles, developers could make wrong assumptions on what they are making. Without taking the time to understand user stories correctly, we could end up making big changes to the codes that could have been avoided.
3. It's not enough to have the "correct" process or the "best" practice
Take the time and have conversations with your team to understand why you are doing what you are doing with process and tools, and how people on the team work together with it. Things can go wrong if we just follow them blindly.
4. Focus on working software rather than comprehensive documentation
There are many kinds of documentation are very useful for the team including wireframes or sequence diagram, but is not the goal to the project. Documentation is only a means toward the end of working software.
5. The term "Working software" has a specific definition
"Working software" is not just the software that is functioning. In a Scrum team, Working software is the software that adds value to the organization.
6. Be cautious when you are constantly "negotiating" to protect yourself
When teams don't collaborate toward the single goal of delivering working software, they often treat each other as if they're working on a contract. It may protect us from getting into trouble when things go wrong, but is highly counterproductive.
7. Constantly look for changes
If we work the wrong plan, we'll build the wrong product. However, it's common for a person who built a plan to resist changing them. Even that's the case, changes cost more later on, so constantly make effort to find out necessary changes as early as possible.
8. Principles add life, character and heart into Practices
A team cannot get the full benefit of solid practices without principles. In order to gain the full benefit of agile practices, do not kill collaboration by only thinking about developer stuff. Have a lot of communication to see the project in the perspective of a team, not your own perspective as a developer.
9. Scrum Master doesn't own the plan
Everyone on a scrum team owns the project. The Scrum Master guides the team's decisions, use of Scrum and its principles.
10. Product Owner makes decisions on behalf of the business
Product Owner doesn't just sit around to wait for the sprint to finish. They work with all of the team members every day, being the voice of the business, to help the team to understand the value of software. It is important to actually listen to the product owner's opinions and ideas.
11. Programming isn't the only important thing in a project
Many programmers take the attitude, and many companies encourage this when they structure their teams around a core set of technical people. Be wary when you see everyone else except developers as "outsiders".
12. Be cautious when prioritising your own professional goal
When we have this mindset, we are not committed but merely involved in the project. During a sprint, the success of the project is more important than getting closer to your own professional goal. For instance, if we choose technology for the project because we want to learn it, we are putting weight on our own professional goals, rather than the success of the project.
13. The more people outside the team involved, the more value he or she can potentially add
For instance, users of the software should be involved because their opinion matters. That's one of the reasons to release working software to the users on a regular basis to keep them involved.
14. Collective commitment rather than committing to individual tasks
When a team makes a collective commitment, that means each team member agrees and commits genuinely to deliver the most valuable software they can to their users and stakeholders at the end of each sprint.
15. Task assignments come from the team member themselves
The team members themselves are the source of the task assignments.
So ask yourself what you think you should do, rather than simply asking the team lead what your next task is.
16. Daily Scrum is not a way for the team lead to manage the schedule
Daily Scrum is a stand-up meeting. It's for the team to plan the next day's work but not for the team lead to get status updates. To achieve it, each team members inspect the work that the team is doing. It gives the flexibility to make the right decisions including task assignments in the last responsible moment.
17. Ask each other 3 questions every day on the Daily Scrum
Ask these three questions:
- What have I done since our last meeting?
- What am I planning on doing between now and our next meeting?
- What roadblocks are in my way?
By everyone on the team inspecting what everyone else is doing in the same way every day, a lot of problems get caught before they become costly.
18. Pleasant surprises for users/stakeholders can be almost as damaging as unpleasant ones
Avoid any surprises at all cost. To do so, keep everyone up to date on all of the changes they discover during the daily scrum. That's why the attendance of users/stakeholders to the Daily Scrum is valuable.
19. Have a concrete definition of "Done"
For developers, it's easy to feel like it's finished when looking back at what they've just built. But calling it "Done" in this situation can create problematic misunderstanding on the team because your "Done" is ambiguous for anyone else on the team.
Get used to refer Condition of Satisfaction/Acceptance Criteria which defines the concrete definition of "Done" for the task. For each work in the task to get it done, it must also be understood, built, tested and deployed.
20. A lifetime to master
The basic practices of Scrum are straightforward to learn and adapt, but there'll be many challenges if we want to master it.
While I was reading through the book Learning Agile to write this summary, I was also reading a book called "Courage to be disliked" written based on Alfred Adler's theories in tandem. As reading through this book, I noticed that there are many things in common with Scrum and Alfred Adler's theories. It was an interesting realisation.
If you don't buy some practices of Scrum, I highly recommend reading the book Courage to be Disliked, and not to mention, Learning Agile.
Thanks for reading!
