Scrum novices can start here

Head of IT WEB Kasper Fehrend and Scrum Master Brian Fischer, who both are highly experienced at creating effective Scrum teams, explain the multifaceted role of the Scrum Master, the essential Product Owner and high-level planning.

Scrum is easy enough to learn. The challenge is adapting the model to the reality of the individual organisation. Even though Saxo Bank and Scrum are a match made in heaven, since the method can handle the constant flow of input the bank receives, it still takes a lot of legwork to build bridges between operations and IT. The man who has a black belt in precisely that discipline is Scrum Master Brian Fischer.

Between the business and the team

Half of Brian Fischer’s time is devoted to working with the business side of operations, planning what will happen in the next sprint and making sure that everyone understands their upcoming tasks. The other half is spent making sure there is a good flow of tasks to the developers and that all impediments have been eliminated once the new sprint starts.

‘You are the link between the business and the team – and you have to make sure the interaction is smooth,’ says Fischer, who has seven years’ experience as a Scrum Master.

Compared to traditional project management, you have to be very detail oriented to make it as a Scrum Master, since you are ultimately responsible for making sure the tasks for the next sprint are clearly defined. Kasper Fehrend, who joined the bank in 2008 and was one of the first to use Scrum by the book, does not believe it is an advantage to be a classical project manager:

‘If you know code and understand the dynamics of software development, you know where the value of Scrum lies, and if you facilitate that understanding, the path from the business to the developers becomes much shorter. Classical project managers have a hard time with Scrum because the Scrum Master’s most important task is to make himself redundant.’

Fehrend is no longer a Scrum Master himself. He tried wearing that hat for a couple of years, but realised the role was not for him. Accordingly, IT consultant Brian Fischer was brought on board and the two of them now share the tasks. Fehrend takes care of people management and the technical side of the solutions, while Fischer handles administration and interfacing with operations. Fehrend is engaged in equivalent cooperation with two other teams.

Dedicated Product Owner

For nearly all Scrum teams, it is a constant challenge to get the business on board in the form of a dedicated Product Owner. The role is important – without solid requirements, you risk wasting the team’s time. When Fehrend and Fischer’s current project, development of TradingFloor.com, started three years ago, it was clear that the volume of tasks would require more time than the business manager for the area could give them. In response, they asked the business to appoint a dedicated Product Owner.

‘Being a Product Owner on the TradingFloor project is more than one full-time job. Our Product Owner is supported by two graphic designers, a UX consultant and others – we have a team of people who make up the overall Product Owner role,’ Fischer relates.

There are great differences in how much time operations dedicate to their Scrum teams at Saxo Bank as well. The Scrum Master has to step in and help the teams whose Product Owners are pressed for time. Fehrend says:

‘A good Scrum Master is able to push their Product Owner in the right direction and show how minor tweaks here and there can produce more value. The two should complement each other in relation to what should be produced.’

High level planning

Even if you are running a Scrum process, it is still possible to have ‘high level’ plans – it just works a little differently to what traditional project managers are accustomed. In relation to major features, the Scrum Master may work out a relative estimation in story points. The team’s current project is made up of 30 major features, or stories. Fischer knows two or three of them and has an idea of how much time they require. This makes it possible for him to assess the time requirement for other features. He delivers the overall estimate at the roadmap planning level. He explains:

‘Our high level forecasts are necessary to secure resources and management commitment to the project we are working on. It works OK, but we also know very well that the plans we make now for what we will be doing in three months will have changed by that time.’

Fischer wants to understand the business roadmap and what features have to be delivered further on, but he does not want the team to be given detailed requirements too early on. He knows from experience that it is a waste of energy to specify requirements in detail before IT is ready to develop.

‘We know changes are going to be made if we do it too early.’ This is one of the elements of Scrum that differs significantly from waterfall projects. ‘We accept that the requirements will come at the last minute – but it works for us,’ he explains.

Inspect and adapt

Most businesses adapt Scrum to the organisation’s reality. For example, a lot of people are inclined to skip the retrospective meeting after a sprint, especially if they have a conventional project manager mindset. It is expensive to have an entire team sit down for a two-hour meeting every 14 days, and it can be difficult to qualify the benefit. But there is no doubt in Fehrend’s mind as to the value of the meeting. At the last meeting, it emerged that tasks had not been broken down to a low enough level. 

‘That generates questions, so we had to bring the Product Owner closer in. We agreed to break down tasks further and that in future the Product Owner will sit next to Brian. If we had not had that meeting, there would have been no change,’ says Fehrend, who posts the results of meetings on the board so that everyone can see what went well and what went wrong. He continues:

‘”Inspect and adapt” is one of the mantras of Scrum. So, the retrospective meeting is everything because this is where you inspect and adapt. Not only to the business, but to the process, which evolves and becomes more efficient.’

From an isolated viewpoint, Scrum has been a big part of significantly improving Fehrend and Fischer’s team over the last few years. One of the major improvements is the entire delivery model for how code goes from idea to live feature as swiftly as possible. The model was optimised iteratively over six months to a year.
Fischer explains:

‘It was done in small steps, sprint by sprint, where we looked at what we needed to be able to do things just a little better. The Scrum model is incredibly simple, but the things we achieve with it are invaluable to us as a team.’