Practices and Tools

There are several practices and tools that you should try during the project. They may work for you, or they may not. By trying them out, and reflecting on the results, you will know more about which practices and tools are the best ones for you.

What follows is an alphabetical list of practices and tools, with short explanations.

Backlog Refinement

Ideally, backlog refinement should take place continuously. But sometimes, a team can get caught up in other stuff, and a meeting can help make refinement actually happen.

If possible, schedule a meeting for backlog refinement at the beginning of the sprint, but before Sprint Planning. In this meeting, the team makes sure that all the highest-priority items in the backlog are clearly understood by the whole team, have a desciption of "how to demo", a definition of "done". Preferably, the highest-priority items should also be split into tasks, and be estimated. See also parts two and three in the book: "How we do product backlogs" and "How we prepare for sprint planning".

Brainstorming

Brainstorming is a method for finding new ideas, such as "which product could we do?". You need a whiteboard, a whitebord-pen, and around 15 minutes. Choose a secretary - someone who can write fast. Then everyone speaks out ideas, and the secretary writes them down.

Important: during brainstorming, only new ideas are welcome. Any criticism or discussion must be saved for later.

After the brainstorming, take photos of the whiteboard as a record of all your ideas. Then set up a separate session for discussions.

Code Review

Code Review means that several developers read the code and try to suggest improvements. A code-review meeting can involve several developers, or the whole team.

When setting up a code-review meeting, decide on a specific part of the code base, and on one or two areas of focus. Examples of areas of focus are simplicity, absence of repetition, or the SOLID design principles.

Pairing is often seen as a kind of code review. Make sure to try code-review meetings as well.

Continuous Integration

Typically, developers make local designs of each part of the project. Integration is when these local designs are combined into a complete prototype.

If integration happens rarely, errors or incompatibilities can go unnoticed for a long time. The term continuous integration is used when integration is automated and can happen many times every day.

Daily Scrum

Daily Scrum is a 15-minute meeting, usually done standing-up to keep it short, and to the point. The purpose of the meeting is to distribute work the best way.

One way to do it is to let each team member answer three questions:

• What did I do yesterday to help our team meet the sprint goal?
• What will I do today to help our team meet the sprint goal?
• Do I see any problems that could stop the team from meeting the sprint goal?

As part of the meeting, the team checks that the taskboard is up-to-date.

The Daily Scrum should always happen at a specific time and place, every day. Most teams find it best to have the Daily Scrum in the morning.

Instant Meeting

A developer can sometimes discover a problem that needs the attention of the whole team. Either, solving the problem would affect the whole team, or the developer needs to discuss various solutions. In this situation, the developer should call for an Instant Meeting to discuss the problem.

If a team has Instant Meetings too often, the team can decide that developers should talk to the Scrum Master first. The Scrum Master would then decide if an Instant Meeting is necessary. However, most teams don't need this level of bureaucracy.

Pairing

Pairing is also called pair-programming, or pair-work.

In programming, pairing means that two developers work together at one machine, in a dialog about the code. One person (the driver) writes code, while the other (the observer) reviews the code as it is written. This method can be applied to other work than programming, such as, building hardware.

Pairing is tiring. Therefore, it is important to make frequent breaks, make frequent switches of roles between driver and observer, and to rotate the roles through several (or all) people in the team.

Rule of thumb: pair for 25-40 minutes. Then take a 5-minute break, then switch roles. After about two hours of this, change to another way of working.

Planning Poker

Planning Poker is a technique to engage everyone in estimating what is required to finish a story. You can read about planning poker in the book, and on this web page: https://www.crisp.se/bocker-och-produkter/planning-poker Links to an external site. (link checked 2024-03-04).

Product Owner Help Center

If you're a Product Owner in this course, there is a short video that will be useful to you. The video is by Henrik Kniberg, and is called "Agile Product Ownership in a Nutshell".

A couple of expressions in the video may require some explanation. A "spike" is when developers read up on something, and/or write throwaway code to test a new concept. "Backlog grooming" is now usually called "backlog refinement".

Link: https://www.youtube.com/watch?v=502ILHjX9EE Links to an external site. 

Retrospective

The Sprint Retrospective is the most important Scrum event, according to Henrik Kniberg's book. See the chapter "How we do sprint retrospectives", pages 83-94. Here follows is a brief summary.

This meeting is about methods and ways of working. Technical discussions must be deferred to another meeting.

First thing: select a secretary. The Scrum Master and the Product Owner have special roles already. Therefore, one of the others should be secretary for the retrospective.

The Scrum Master summarises the sprint in no more than 1 minute. State the sprint goal, did we achieve it, was there any important events or decisions?

Do "the rounds". Each person gets to say, without being interrupted, what was good, what the team might try next sprint, and what could have been better. Any discussion is deferred until after "the rounds".

After "the rounds", it is usually clear what the most important thing is, and the team can start discussing that. The focus should be, how can we make the next sprint better?

Near the end, the Scrum Master gives a short summary of the most important discussions, with help from the secretary. The end result should be three groups of bullet points:

1. Good: Which methods were good - make sure we continue to do them.
2. Try: Which new methods should we try next sprint (up to three items, trying too many new things at once doesn't work).
3. Problems: Which methods didn't work for us (so we can stay away from them).

The first two groups of bullet points are positive, and contain good things that the team should do. The last group is negative, with things that should be done differently. The problems group can sometimes be empty.

Rotation

Rotation means that the team members regularly switch tasks, so that every team-member eventually gets to do every task.

Rule of thumb: when pairing, rotate one of the members of each pair every 4 hours.

The opposite of rotation is specialization. This means that you do what you're good at, and you do it through the whole project. Specialization has at least two big drawbacks:

1. Specialization makes the team fragile. If the only team-member who knows X gets sick, then all work on X grinds to a halt.
2. Specialization stops team-members from improving a skill they're not already good at. This goes against the goal of the course: to help everyone towards realizing their true potential as a developer.

For these reasons, specialization is disapproved of in this course, and does not get an entry of its own in this list of recommended practices and tools.

Scrum Master Help Center

If you're a Scrum Master in this course, read the short section on Scrum Master (pages 6 and 7) in the official Scrum Guide (link below). Then read Kniberg's book chapter Scrum-master checklist (pages 162 and 163). Then check Henrik Kniberg's Scrum Checklist (link below, the same link as in the book chapter).

When in doubt during a meeting, it can be helpful to refer to the Scrum Guide. As an example, let's assume someone says "We must do X" during Sprint Planning, and you get suspicious about X. Is that the right thing to do? You bring up the Scrum Guide, lookup Sprint Planning (pages 8 and 9), and then you can confidently say "Hmm, the official Scrum Guide says we should do Y, which is the opposite of X".

A good place to learn more is the Scrum Alliance. The Scrum Alliance certifies Scrum Masters and other agile professionals, and publishes many helpful videos and short texts. The link below includes a search for "Scrum Master". Some material is for members only, but there is a lot of open stuff that everyone can access.

When looking to learn more, be careful where you look. There are many people and organisations claiming they do Scrum, but in fact they have modified it almost beyond recognition. The links below are good and can be trusted (checked 2023-03-31).

Henrik Kniberg's recommended Scrum Checklist: www.crisp.se/gratis-material-och-guider/scrum-checklist Links to an external site. (checked 2023-03-31).

Scrum Alliance Resources: https://resources.scrumalliance.org/?sp=scrum master Links to an external site. (checked 2023-03-31).
In particular, you may want to read the short article What I Wish I'd Known As a New Scrum Master: https://resources.scrumalliance.org/Article/wish-id-known-new-scrummaster Links to an external site. (checked 2023-04-20).

Scrum Guide: https://scrumguides.org/ Links to an external site. (checked 2023-03-31).

Semat Alphas

The Semat Alphas are a way of assessing the progress and health of a project. There are seven Alphas, and each of the Alphas can be seen as a small deck of 5 or 6 cards. On each card is a checklist.

To assess the progress and health of the project, the team works through the seven decks of cards. With each deck, the team starts with the lowest-numbered card and checks off items on the checklist. If all items on the checklist are done, the team continues on to the next higher-numbered card.

For each of the seven Alphas, the highest-numbered card with all items checked corresponds to the state of that Alpha in the project. If the states move more-or-less in sync for a project, then the project is probably in good health.

However, it can happen that a project makes progress in most Alphas, but has stopped at the first or second state for some particular Alpha. This indicates that there is a problem in the area corresponding to that Alpha. Working through the Alphas periodically gives the team a chance to find problem areas before they become critical.

Semat: Essence Explained 
Link: www.ivarjacobson.com/essence-explained-agile-tools Links to an external site. (accessed 2023-03-31)

Social Contract

Before the start of the project, set up a one-hour meeting with the whole team. Put away phones and computers, and take out pens and paper. Each team member then writes down 5 social rules for a good workplace.

When all team-members have finished, the rules from all team members are put on the table for discussion. The team then agrees on and writes down 5 social rules for the whole team.

Test-Driven Development

In test-driven development, a developer first writes an automated acceptance-test. Following that, the developer writes just enough code to pass the test. Last, the developer rewrites the code to improve readability etcetera.

In effect, the test is an executable description of what the code should do. Therefore, test-driven development makes the developer decide exactly what the code should do, before actually coding. This can result in considerably improved code-quality.

Version Control with Git

Version control enables teams to manage changes made to documents; in particular source code. There are multiple different version control systems (sometimes abbreviated VCS), such as Git or Apache Subversion (SVN). In this course students are encouraged to use Git, and Git will be covered in some introductory lectures. As some concepts may seem quite daunting at first, we recommend getting started as soon as possible.

The resources below are recommended, together with the lectures presented during the course. Please start with the Backlog Git Guide, which tells you what you need to know to get started with Git. To understand branching better, please also try the interactive learning tool "Learn Git Branching".

Backlog by Nulab: Backlog Git Guide - What is Git?
Link: https://backlog.com/git-tutorial/what-is-git/ Links to an external site. (accessed 2018-12-10)

Peter Cottle: Learn Git Branching. 
Link: https://learngitbranching.js.org Links to an external site. (accessed 2018-12-10)