Service Design goes Agile Why service design is a perfect match with agile software development
Jens Otto Lange is a design facilitator at GuentherLange. He helps teams to co-create innovation for the digital age, working on behalf of such clients as Airbus, Axel Springer and Otto. Jens initiated Service Design Hamburg and contributes to the MoDAL Network exploring the intersection of lean, agile and service design.
62
touchpoint 6-3
Service design defines the why and the what of software, Scrum suggests how to implement and refine it. Both provide an iterative approach that is based on user feedback through early testing, and they both challenge the way designers work with developers. GOING AGILE TO REDUCE RISKS
While navigating through the ‘fuzzy front-end’ of innovation, there’s a high risk of failure, since data from the past plus some assumptions about the future are all you have in terms of knowing how your customers might use your product or service. This is true for every kind of innovation and it’s particularly true for software. That’s why software development teams were among the first to apply agile planning methods. Today, Scrum is the most popular implementation of Agile. It’s a way of reducing the risks associated with complex projects through dynamic adaption to change. Instead of a traditional waterfall project management that specifies every software function upfront, then codes it over months or years for a big-bang release, Scrum shortens the release cycle to a maximum of 4 weeks to enable early feedback by users and business stakeholders. It is a data-driven approach to learning that test
enables you to make better decisions about the future. DISCOVERING THE VALUE OF UX
In Scrum, there is the development team, the ‘Scrum master’ to facilitate the process, and the product owner: people like Paul. The software engineer is responsible for one of the mobile app products of an Internet start-up. In user story-mapping sessions1 with his business stakeholders, Paul drills down their requirements into user stories. User stories describe a requirement from a user’s perspective. Paul is the guy who decides which user stories are to be put on a prioritised list of requirements that his product should meet, called the product backlog. Paul “is the sole person responsible for managing the product backlog.” 2 But Scrum doesn’t tell Paul how to identify the most valuable features or how to involve designers. In practice, most development teams have found that it helps a lot to let a designer enrich
