View all pages

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.

Update (2022-05-13): Backlog Refinement Meeting was added to the list.

Backlog Refinement Meeting

At the beginning of the sprint, but before Sprint Planning, the team has a separate meeting to improve the backlog. 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".

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.

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.

Social Contract

Before the start of the project, set up a two-hour meeting with the whole team. Each team member writes down 5 social rules for a good workplace.

When all team-members have finished, the rules from all team members are copied into a shared document. The team then discusses and writes down 5 social rules for the whole team.

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 User Guide - The Essence Kernel 
Link: http://semat.org/quick-reference-guide Links to an external site. (accessed 2018-12-10)

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)