Digitization is shaking up publishing in a big way. Publishing houses, if they are to survive, cannot afford to set their face against the dynamic in this market, but instead need to exploit it themselves.
In this context, the publishing house Springer Medizin felt the need to adapt its online presence to the changed requirements and to re-launch its website. The demands were oriented to the one-platform strategy and the options available when it comes to today’s end-devices: amongst other things, the aim was to achieve responsive design to shape the content in line with the reader’s equipment, regardless of whether the site was accessed via a conventional PC, a tablet computer or a smartphone.
In the re-launch, Springer had set itself anything but a relatively minor project. Initially, the team comprised a dozen people; all roles were represented (Business, Engineering, Tester and Designer). Software projects tend to steer their own course, both in terms of time and financially. But why should the re-launch team go down the thorny yet unpromising route of traditional project management? Why walk the well-trodden paths of software development into a wide range of problems, when others have already learned that better methods are out there?
Experience within Springer of using the agile working method – scrum, personas, elements of design thinking – was already available, and it had shown that another way is also possible: faster, more flexible, less cumbersome. ‘More agile’, so to speak. With conventional project management, there are three key parameters: project scope, costs and time. That said, it is not possible for all three of these positioning screws to be tightened fast right from the outset. Setting all three generally doesn’t work. Similar to a pressure cooker with the valve screwed shut, such projects then threaten to blow up in the faces of those responsible as the pressure increases. Agile methods offer a way out. The focus here, above all, is on time and budget, and the scope of the project is variable. With agile working, you achieve the best possible product within the framework of the cost and time budget, since it is always the most valuable things from the user’s perspective that are implemented first.
The responsibilities in an agile project are shared out in a different way to that found in a conventional hierarchy. The team organises itself based on the skills and inclinations of the team members themselves; depending on the function, one team member can assume various roles, for instance that of Tester. In the case in question, alongside Developer the team comprised roles such as Business Analyst, User Experience Designer and Product Owner. There is no ‘commanding officer’ looking out from an observation post to see what the various team members are getting up to, although the Product Owner does have a special position to some extent: he is responsible for the content-specific aspects and, together with the Business Analysts, represents the customer perspective.
Because the scope of the works needed for the re-launch was a particular challenge, the Springer team also called in outside assistance – a coach from the corporate consultancy agile42. “We supported them in better understanding and mastering the agile way of working,” explains agile42 coach Ralf Kruse. The challenge here is that each team has already developed particular ways of operating and patterns of interaction and lives these out in its day-to-day work. “Having the view from outside makes it easier to see these things,” confirms Kruse.
Now the task became one of reflecting on these patterns and, where necessary, transcending them in order to make the processes more agile. “We helped the team at Springer to shape their way of working more collaboratively,” adds Kruse. The coach recognised that there were different loci of competencies amongst the specialist domains within the team, and that these were proving an obstruction to fluid communications. “It meant that one of our most important tasks lay in triggering and encouraging early exchange within the project,” comments Kruse.
So how does this kind of agile project work? “The agile approach in this context means step by step implementation with short feedback cycles, and the possibility this offers of being able to change direction at any time,” explains Thomas Vitzky from Springer, who has been supporting the project since February as an internal coach. Instead of becoming bogged down in a list of requirements with no overview, the task is broken down into manageable chunks which are then implemented in short development cycles. Admittedly that too is simply a means to an end; it is a tool which helps in establishing the cooperative and communicative agile way of working between business and engineering, and consolidating that as the new default. It is also important to set priorities (and the right ones). That, in turn, presupposes that the team understands how to structure the task. “Prioritising is a very important keyword,” explains Reinier van Wel, the team’s Information Architect: “agile42 has helped us a lot with establishing the importance of particular aspects, in formulating them and then implementing them.” The decision as to which partial objectives take priority is the result of an agreement process in the whole team. There is no space in this way of working for decisions taken by a line manager at some remove from the practice on the ground; in this process, the only person holding a right of veto is the Product Owner.
In practice, this is more complicated and laborious than it sounds on \paper: the agile approach is based on direct and efficient communication between team members. That does not need an elaborate set-up; short notes and status reports are adequate. To that end, the team met daily for short feedback discussions which took a maximum of 15 minutes each time. As a result, the team learns to create a moderated exchange at an early stage in the project, to rehearse and consolidate close collaboration, and to live out the agile way of working. In this way, the project can be structured meaningfully with minimum time expense. Any need for corrections is identified early on, while risks and uncertainties are discussed jointly and, where necessary, eliminated.
There is no rule set in stone regarding the optimum or maximum size of a team, and much comes down to experience. Vitzky considers the ideal size to be a team of around seven members. “It works with up to ten members, and including the Product Owner and Tester up to twelve,” says Vitzky. The maximum size also depends on which roles are included within the team. “Each team is different,” says the coach. The Springer team grew into its tasks and took the learned approaches to solutions forward independently.
So what is the summary from the client’s perspective? Although the project is not yet completed at the present time (end of July 2014), at Springer the view of the decision to adopt an agile way of working and to call in an agility coach is wholly positive. “We are glad that we are better able to ‘work agile’,” says van Wel: “It gives us greater flexibility and makes it possible to rethink things; it means we can recognise more quickly if we are heading down the wrong path.” And, most importantly: “The communication is working well.”
Customer: Springer Science+Business Media (http://www.springer.com)
Challenge: Re-launch of the internet presence for 4 internal publishing house divisions, with numerous interactive functions, e-learning products and multimedia content.
Programming language: Scala
Project duration: since autumn 2013
Project scope (headcount): initially 12, step by step increasing to 19 employees at present.
Roles represented in the project: Developer, Product Owner, Tester, Business Analyst and User Experience Designer
