Scrum @ XING – a case study

Development projects on XING are very interesting, but can also be very complex and demanding. Just imagine: Hundreds of functions, 16 languages, a variety of payment systems, over 20 technical partners who connect to the website, four revenue streams and over 100 employees involved in developing the platform. At the same time, we have to be in a position to rapidly adapt to changes in the market or business conditions.

To avoid impediments and ensure that our time is spent as fruitfully as possible, we depend on a project management system adapted to our requirements. More specifically, we rely on an agile management system known as the Scrum Framework:

This three-part series of blog posts will explain why we chose to implement the Scrum Framework, the difficulties that came with that decision, and how we finally decided to proceed.

Why Scrum? Agile project management for an agile network

Projects at XING are seldom dependent upon external conditions. We are not required to sell a certain amount of software quickly at the end of a fiscal quarter, and make sure that it includes a fixed definition feature set. At XING, development is mostly driven by dynamic requirements placed on us by our users and our business. Here’s an example: When a website such as Twitter starts growing very quickly, we feel the need to rapidly respond, and offer our members the ability to use the service within the framework of our platform, as we explained in this post

An agile, flexible approach allows us to react quickly and frequently to changing demands. It allows us to adjust our product roadmap, our project planning and our project goals frequently and without resource loss . This quality is a particular advantage of agile software development over a traditional waterfall model which is a sequential approach in which progress flows from one stage to the next, and results are shown only towards the end of the process. Changes or adaptations at this stage lead to substantial impasses in budget and deadline.

Scrum is different: Working at a project level, we can release new features immediately as in-house alphas (and public at a beta level every one to three weeks) and get feedback much quicker than before. Effectively, this means we only commit our resources for a very short period of time, and after that, deliver a finished piece of software that can be published. For you, dear members, frequent releases let you know that something’s happening here at XING, and that you’re part of it.  That is what we mean with our Ship It Strategy. You can help us separate the wheat from the chaff, so to speak, and concentrate developmental resources on the features you really want to have.

But Scrum is not just about faster development: Errors – whether in content or code – can be corrected in real time, because our quality assurance team is integrated into the process from the beginning. The result is that by the time a feature is ready for release, we can ensure a high quality product without an additional test phase at the end of development.  Furthermore, all team members benefit from the close-knit nature of the team, which in turn boosts motivation, encouraging everyone to achieve their potential, even outside of their area of expertise.

In part two of the series, I’ll describe the challenges we faced when implementing Scrum at XING.