Effective team collaboration with SCRUM #1: Choosing a development methodology
Effective team collaboration with SCRUM #1: Choosing a development methodology

Effective team collaboration with SCRUM #1: Choosing a development methodology

Friday, 17 March 2017

Managing a software development project can be hard, it also has a big influence on how effective the collaboration of the team is in software projects. This makes choosing a software development methodology (SDM) an important task when starting a project. There’s a large list of available, well thought of, software development methodologies and every one of them has its pros and cons. Making the right SDM choice will positively affect the outcome and the expenses of the project.

‘Effective team collaboration with scrum’ is a series of blog posts about the pros and cons of having scrum as a software development methodology.

In this blog I’ll give an introduction to what kind of development methodology scrum is and I’ll explain how we decided to use scrum as our permanent SDM. I believe that there is no default SDM which would fit for every team. This makes choosing a SDM for you team a full sized research project(!).

Agile

Since we have chosen to work with a SDM from the Agile movement, I will give a short introduction to Agile. Agile is not seen as a SDM but more as a set of principles for an effective SDM. Agile was a response to the traditional SDM’s. Taking the waterfall method as a classic example for representing these SDM’s, the big difference is very clear. While the waterfall method relies on a sequential, non-iterative, design process, Agile describes that a SDM should have characteristics like adaptive planning, early delivery (by working with increments) and continuous improvements (by working in iterations). This all results in a main principle that a SDM should have a rapid and flexible response to change.

Scrum

Although scrum existed before the Agile movement, it’s nowadays seen as an Agile software development framework. Like the Agile principles describe, scrum focuses on the fact that a customer can change his mind about what he wants or needs. Scrum accepts that a customer's problem cannot be crystal clear and tries to advance the development speed and the team's ability of delivering quickly, which makes it possible to respond and adapt to new or changing requirements. A full scrum project is build out of sprints. A Sprint is the same as an iteration and it has a fixed duration that’s set in advance for each sprint.

Roles

In a scrum project three roles are defined. I’ll give a short explanation of what these roles exactly come down to.

Scrum master

A scrum master is a team member with high knowledge about scrum. His task is to coach the development team and the product owner on the scrum process. He will adjust the team process when needed to get the best scrum process as possible. The scrum master will also manage every scrum event, aiming that it will be as efficient as possible.

Product Owner

The Product Owner (PO) role can be done by the actual product owner or by a project manager which will be a proxy to the product owner. The PO focusses on the market around his product so he understands the business and market requirements. The PO gives input to the development team and prioritizes the backlog.

Development team

The development team (or the scrum team) is a multidisciplinary team of developers. Each member has the same goal: a successful sprint completion. Besides the obvious development tasks, the development team is also the key actor in steering the project and individual Sprints. The development team gives an estimate on how much work they think a backlog item takes, and thus which items can be completed in a Sprint.

Events

In scrum we know several events that will be repeated every Sprint. I’ll give a description of the most common and default events in a scrum project.

Planning

The Sprint planning event is held at the beginning of a Sprint. The purpose of this event is to communicate and create a scope of work that will be done during the Sprint. When the scope is clear, items from the backlog can be selected to be completed in the Sprint. These items together are the Sprint backlog. During the planning event the Sprint backlog will be discussed in detail so every item in it is clear and is decomposed into tasks. At the end of this event every item is timeboxed and in most cases the tasks for each item will be given an estimate of how long it will take to complete the task. This can be done by planning poker, which is a ‘game’ in which each project member gives an estimate for the task. Different members can give different estimates, which are then discussed resulting in one estimate everyone agrees to.

Daily scrum

Each day during a Sprint a Daily Scrum, or daily stand-up, is hold. During this event all members of the team have prepared the answers to three questions. These are: What did I do yesterday?; What will I do today?; Do I see any issues preventing us to meet the Sprint goal? The Daily Scrum is always timeboxed to fifteen minutes and is always held at the same time. The fact that it’s timeboxed makes it impossible to discuss details, this is the intention. The Daily Scrum is meant to give the team a short update and give each project member a quick overview of the status of the Sprint.

Sprint Review

At the end of a sprint two events are held by the team. One of them is a Sprint Review. During this event the team reviews the work that was completed during the Sprint, but also the work that was not completed during the Sprint even though it was planned. In this event the team also demonstrates completed work to the stakeholders in the form of a demo. This event is also used to update the stakeholders on the progress the team has made during the sprint.

Sprint Retrospective

The other event which of the team at the end of a Sprint is the Sprint Retrospective. During this event the team reflects on the past Sprint, but instead of focussing on the work, the team focusses on the development process and identifies which improvements can be done to make the future Sprint a better one than the past Sprint. During the Sprint Retrospective no stakeholders are present.

Backlog refinement

The Backlog refinement event (or Backlog grooming) is an extension to standard scrum, but has been given a place in most scrum projects. During this event the team will iterate over all backlog items which are most likely to be put in the next sprints Sprint backlog. The team will check if an item needs more clarification or has to be split up into multiple smaller items. Since this event is an extension to standard scrum, it has no default place in the scrum timeline. Most of the time the team will decide when a refinement session is needed, before starting the next Sprint.

Our scrum process

For projects we do within Transceptor Technology we use a pure form of scrum. There are two main reasons why we chose for scrum.

  • We want a structured development process

  • We want to be transparent towards stakeholders

Normally interference from stakeholders can be inefficient, but low-transparency towards stakeholders can result in a product that does not fulfill all requirements, or at least not in the correct priority. By using scrum as our go to SDM we’ve been able to be transparent and still have an efficient development process.

Go to SDM?

Yes, scrum is our go to SDM. In most cases we use scrum as our SDM. Of course when we start a new project we will first verify if scrum is an effective SDM to use for that specific project, but our experience shows us that most of the times we can use scrum, because scrum is easy to adapt in most projects and our team is working perfect when using scrum.

In the upcoming parts of this blog I’ll go more in depth about what scrum means exactly for our team’s efficiency and the general pitfalls of scrum, so keep tuned!