blog comfone header

Implementing SCRUM at Comfone: a success story

Comfone-development-rela_20201008-095208_1


I am the EVP Development at Comfone. Part of my role involves achieving the best possible results for customers by coming up with more effective ways of working.


Although we often work behind the scenes, Development is a really important component of Comfone. Focusing on this area can create more efficiency and agility, allowing us to do more with our current resources.


This in turn will mean that customers have even better services and applications within quicker timeframes. We will also be able to create more new features that can benefit our customers in many different ways.


Here at Comfone, we have recently changed our development process from a combination of waterfall and agile development to the SCRUM methodology. 


Defining terminology 

There are many different terms which are used when discussing development. But do you know your waterfalls from your SCRUM? Let me give you a short introduction and background on the two different methodologies.


Waterfall development 


Waterfall-model development sees you writing down each detailed requirement before starting to develop the first line of code.  


The disadvantages of waterfall development 

It's possible to spend weeks or months writing specifications without seeing any real progress on the application.


Requirements might change within those months, leaving the initial planned scope unable to fulfil real market needs.


Even the best service managers might face difficulties writing a fully correct, consistent and complete scope.


As soon as the service manager sees the new developed application for the first time, they might have new ideas for additional features, and some of the initial features might need changes - or worse –become obsolete. However, the development time has already been spent.


A schematic overview of waterfall development

SCRUM 


SCRUM follows a different path.


It is an agile framework for developing, delivering and sustaining complex products within short timeframes. These are called sprints.


Sprints must be no longer than one month and typically take two weeks. At the end of the sprint, the team holds a review in order to both demonstrate and retrospect the work achieved.


In comparison to the waterfall-method, SCRUM development starts immediately with the first written requirement.


The great thing is that after the first two-week sprint, the stakeholders already see some achievements.


How did we implement SCRUM? 


We divided our developers into four different SCRUM teams.


Each team looks after their individual product backlog, which is assessed and prioritized by the respective service manager from Clearing, IPX & Hubbing, DMS and Pulse.


Sprints run over two weeks, and within these parameters my developers work towards the agreed sprint goal to get a new increment deployed and on production. 


SCRUM framework 

The SCRUM Framework (https://www.scrum.org/resources/what-is-scrum)


Stage 1: Product Vision 

The product owner – in our case the service managers – creates a product vision which they share with the developers and other stakeholders.


The vision roughly describes both the direction of the product and application development, as well as sharing some high-level use cases. 


Stage 2: Product Backlog 

In this stage, the product owner will add all the high-level use cases into the product backlog. These items do not need to be very detailed.


The items that the service manager considers top priority will be refined and written in more detail to ensure that the developers understand the real needs of this product backlog item.


It's important for the product owner to full describe the use-case, so that our developers can effectively plan the next sprint. The other use-cases remain on a high-level description.


Stage 3: Sprint 


The development team now chooses which product backlog items they can develop within one sprint.


They commit on those items and start working on the sprint backlog items only. This helps to keep the focus on the actual development – the only dilutions accepted are potentially urgent bug fixes. 


Stage 4: Increment 

At the end of a sprint, a new product increment can potentially be released into production.


With this approach the service manager and as well the stakeholder gets the chance to inspect the adaptions on the products and applications every two weeks.


Close working between service manager and developer helps to avoid any big detours in development.


Does it work? 

We are now approaching the end of our second sprint, and we can already see big benefits.


The service managers are working closer than ever with the developers, which has increased transparency because everyone can see which items the teams are working on.


Communication within the development team has increased, as the SCRUM teams now share one common goal within a sprint.


Knowledge transfer has also increased. 


The future 

I really look forward to the coming months, as we grow our experience with the agile development. I am convinced that we will be able to continue to serve our customers with easy-to-use and reliable applications.

Insight into our Development room
My monologue on how we achieve global connectivity

Related Posts

By accepting you will be accessing a service provided by a third-party external to https://www.comfone.com/