Scrum

Scrum is a rugby term

Scrum is an incremental and iterative framework for managing software development projects.

Based on our experience, it is appropriate in the following cases:

for teams that want to improve their productivity
for teams that start adopting agile practices
for teams that work in outsourcing or with internal customers

Scrum‘s strong points are:

it helps create a rhythm in the team
the practices were hand-picked based on practical experience and work very well together
it provides an excellent support for continuous improvement

The Scrum process as it was originally defined

The Scrum framework has:

3 roles: Product Owner (representing the client), Scrum Master (coach/facilitator), Team (people doing the work)
4 meetings: Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective
5 artifacts: Product Backlog, Sprint Backlog, Impediments List, Release Burndown, Sprint Burndown

The typical Scrum team’s activities are:

At the beginning of the project, the Product Backlog is created by the team based on the input from the Product Owner, including vision, goals and features. An initial roadmap is created.
Before the sprint, a Sprint Planning meeting is held where the Sprint Backlog is created by the team based on the input from the Product Owner and on the Product Backlog. The team decides to commit to delivering a certain set of items.
During the sprint, the team meets for a short discussion each day – the Daily Scrum. All team members work together towards the same set of goals, and this meeting allows them to synchronize their efforts.
At the end of the sprint, the team proves during the Sprint Review meeting to the Product Owner that the items from the Sprint Backlog were implemented. The team must show working software, with all functions working. The Product Owner can refuse the items which are incomplete or don’t work correctly.
The sprint ends with a Sprint Retrospective, a meeting during which the team analyzes the process, identifies impediments and defines actions meant to remove the impediments. Experiments that have potential benefits for the team can also be put in place.

In order to learn more about the basics of Scrum, you can read the Scrum Guide.
We have seen the following typical problems when adopting Scrum:

Lack of incremental/iterative thinking
- Moving from waterfall to an incremental and iterative approach of defining a product is a difficult change in mindset. If this change doesn’t happen, teams end up with waterfall masked as Scrum.
- You have this problem if the team develops only “complete features” or “modules” instead of increments (i.e. small improvements affecting one or more parts of the application)
Not a real team
- Team members must cooperate at all times. They have to know what everyone’s doing and why, and if one of them is stuck the others jump to help him/her.
- Testers should be part of the team.
- You have this problem if the Daily Scrum is boring because each member of the team works at his/her own tasks that are completely disconnected with the others’.
“There’s nothing to improve”
- All teams can improve the way they work. Sometimes small things can help (e.g. stop using the mouse for development). Other times, new practices need to be added (e.g. TDD).
- You have this problem if the team finds the Retrospective useless and/or if there’s no action defined at the end of the Retrospective.
The sprint is not actually finished due to bugs or technical debt
- Many teams find that they have a lot of bugs at the end of the sprint and have to schedule them for resolution during future sprints.
- Scrum doesn’t require any specific development practices. It is assumed that the team members are professionals who choose their way of working. Therefore, the team has to discuss this issue during the retrospective and decide on a way to remove technical debt or to reduce the number of bugs.
- Our recommendation is to look at practices like Test First Programming or Test Driven Development, Clean Code, SOLID Principles and/or Pair Programming.