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.
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.
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.
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.
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.
"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.
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.
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.
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.
Everyone on a scrum team owns the project. The Scrum Master guides the team's decisions, use of Scrum and its principles.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
Thanks for reading. If you have any opinion or question, please leave a comment below!