Design and Development in the “Agile Room ...

Design and Development in the “Agile Room”: Trialing Scrum at a Digital Agency Dr. Katerina Tzanidou1 and Jennifer Ferreira2 1

2

Cimex Media Ltd., London, EC2A 4PJ, UK, [email protected] The Open University, Walton Hall, Milton Keynes, MK7 6AA, UK, [email protected]

Abstract. Scrum was trialed at Cimex — a Digital Media Agency in the UK. Our insights centre in particular around the close interactions between the designers and developer working in the same room, and how the design roles were played out in the Scrum context. The lessons learned from this experience are now presented to our clients as a case study in order to make them more aware of the benefits of running an Agile project. Since this trial, we have adapted our current practice to include more immediate forms of communication. We now have handson experience integrating design with Scrum and can say that it was an enjoyable, bonding experience for the team. Key words: Designer, Developer, War room, Scrum, User Experience, Agile adoption, Agile integration

1 Introduction This report is based on the experiences of trialing Scrum at a Digital Media Agency in the UK, called Cimex Media Ltd. We decided to trial Scrum at our organisation for a number of reasons: Although our teams had borrowed parts of Agile methods before, from the organisation’s point of view, it was an opportunity to get hands-on experience specifically with Scrum and to learn how Scrum would work with the existing organisational structures. One of the aims was to bring design and development closer, by seating the designers and the developer in the same room. The idea came from our experience working with a client who outsourced our Information Architect (IA) and asked that he would go and sit in the same room with their developer and designer at their premises. Talking to the IA about his experience at the client’s premises prompted us to consider whether doing the same could also make our process easier and quicker. It was also clear that the IA enjoyed the experience. From the client’s perspective an emergent solution, via feedback on actual working software was seen as a valuable way of overcoming the fact that requirements were not known up front. This made the project a good fit with our own motivations to try Scrum. Since completing the trial we have incorporated some of the lessons learned into our current practice and can share our insights with other practitioners who

2

Tzanidou, K. et al.

have similar aims. Our insights centre in particular around the close interactions between the designers and developer working in the same room, and how different design roles were played out in the Scrum context. We have also concluded that while an Agile approach has allowed us to be more flexible towards our client requirements it does not suit all projects and all types of clients we deal with. Our public sector clients, for example, still prefer more traditional approaches and prefer detailed definitions and scope in advance.

2 Cimex and Agile While we have separate teams at Cimex, such as Development, Design, User Experience, Content/SEO, Project Management and Producers we work collaboratively across teams and we apply User Centred Design (UCD) processes on all of our projects. As an organisation, Cimex goes back to 1994 and have been using very waterfall-based PRINCE 2 methodologies for several years. As our clients’ needs change we have aimed to explore new methodologies ourselves. Katerina, as Head of User Experience (UX), spent a whole year bringing awareness of Agile methods to Cimex. It has been a challenge to get internal enthusiasm and commitment from all for such a big change. Maintaining trust internally, as well as with the client, was the biggest challenge we were faced with. This was after all a change to what people were familiar with and had been doing for a long time. It was difficult to get everyone internally to buy into the idea and overcome fears of the unknown. We had to explain that starting a project without detailed scoping documentation meant that we had to learn to work collaboratively, stay flexible and learn to trust our colleagues. We needed to build trust that what we agree in our brief meetings in the morning would be delivered by the end of play. Teams at Cimex have borrowed from Agile methodologies in the past, although we had not adopted a coherent Agile method such as Scrum before. We started adding Agile aspects to our projects in 2008 and slowly each individual involved has become more familiar with Agile approaches. Those involved in other Agile projects had enjoyed the experience and were enthusiastic about taking more Agile practices on board.

3 Trialing Scrum We had some specific goals in mind with this trial, which were also influenced by the type of project we had taken on: – Bringing design and development closer together. Prompted by the IA’s enthusiasm for working closely with developers, we wanted to enable the team to work closely and in the same working space. We believed that proximity of space would make a difference in how the team would engage and

Design and Development in the “Agile Room”

3

discuss, and we were hoping that this set-up would encourage more communication and more effective decision making. Traditionally, the team would tend to meet only when a meeting was set up by the project manager. However, we wanted them to feel free to ask each other immediate queries that came to mind while working. – Allowing a creative solution to emerge via frequent client input. The client was keen to be heavily involved in the project. They wanted to be able to give feedback and make changes on-the-fly in order to get the best possible results. By having the whole team working in an Agile way we hoped for more flexibility to make quick changes if needed. – Learning about the practical issues surrounding Scrum adoption at our organisation. We wanted to explore other ways of adapting Agile, such as bringing the Agile team together in one room, having daily quick meetings and client involvement. We expected better outcomes, more transparency and engagement, as well as quick turnaround. The project chosen for this trial was redesigning a client website. We had to keep a really tight reign on the resources we were using, as the client reduced their initial budget by 2/3 but still wanted a high impact website. The client was prepared to allow the creative solution to emerge and had agreed to be heavily involved. Scrum was seen as the ideal methodology to micromanage every aspect of the project with the client being closely involved. The team consisted of one software developer, two designers (a creative designer and an IA) and a project manager who was also the Scrum Master. The creative designer was responsible for the graphic design and the IA for producing wireframes. The developer was responsible for providing the back end code for the front-end designs. The team could work independently and they were not expected to integrate their work with other teams. This was their first experience with Scrum.

4 Life in the “Agile Room” Figure 1 shows the team working environment. Management agreed that the team could be seated in a room that would normally be used as a meeting room or a usability lab. The team were seated at a large table, each at their own workstation. Colleagues would come and visit the team during the day and playfully ask: “Is this the Agile Room?” Or, “Are you the Agile team?” The project manager/Scrum Master was not seated in the same room, however he popped in at regular intervals during the day to answer questions and discuss project-related issues with the team. Basecamp1 was used to share documents and log discussions with the client. The team reflected that in this room they were able to focus free from distractions. Sprints lasted one week, including one to two client meetings per week where the website was demoed and further requirements were discussed. The team began each day with a short standup meeting, to discuss their progress and what 1

http://basecamphq.com/

4

Tzanidou, K. et al.

they were going to work on during the day. As hoped, the team were talking and asking each other questions. The developer explained how valuable it was for him to be aware of the work of the designers. He could spot areas in the design that would cause problems for the implementation: “And that generally probably wouldn’t have been spotted until all the wireframes had been signedoff, handed over and the designs would have been done.” The team were making decisions together. For example, in a discussion about exploring alternatives to a drop-down list, one of the designers asked the developer directly whether her idea would be more difficult to implement. The developer could immediately give her an answer: “It would probably be just as easy.” We counted the instances where the developer and the designers were talking to each other. On their first day together there were 27 instances where questions concerning client requirements were raised, 19 instances of talk about possible design solutions and 14 instances where the designers were directly asking the developer for feedback about either a design idea or client requirements. The team agreed this was more interaction than they normally have when sitting apart. The team had a very positive response to the outcomes of the trial. They all enjoyed the experience and indicated that they would like to work in a similar manner in the future.

Fig. 1. The team in the “Agile Room”.

Design and Development in the “Agile Room”

5

5 Outcomes Instant decision-making and making progress. When driven by tight deadlines we did not observe this kind of quick and efficient communication between team members when they were sitting apart. Small requests for clarifications often get lost along the way as team members are not easily motivated to get up and move around to talk to their colleagues. Instead, they are keen to get the work delivered and quite often only approach their colleagues once they have an issue they can not solve themselves. By placing the developer and designers together sped up the whole development effort and made it more effective. For example, while the IA was creating the wireframes she could ask the developer immediately about functionality constraints. In a similar manner, when the creative designer was working on the look and feel she would have quick access to the IA next to her and ask for clarifications. There were immediate responses to questions concerning design possibilities, but there were also immediate responses to questions about how long a design would take to implement in terms of code. In this way the team had the opportunity to resolve issues that would only have been identified further down the line when it would have had major implications. Before, the designers and developers communicated just prior to the client meeting — usually too late to address the technical problems in the design. Being together ensured everyone was negotiating the way forward together and making progress. The client requirements at the start were very vague and this would normally hamper progress on the project. However, the team asked each other “What do you remember from the client meeting?” “What did you understand the client wanting from the client meeting?” Allowing them to move forward by sharing their knowledge and opinions. Understanding design roles. At Cimex we have several types of design that is carried out by different roles. For example, the IA designs the structure of the site, navigation and layout, whereas the creative designer is responsible for aspects such as the aesthetics of the site, the use of colours and the logo. Using Scrum inevitably means that the various design roles need to integrate and coordinate their work within the Sprints. Design at Cimex can not simply be added on to the Scrum methodology. We came up against questions such as how to time the tasks of the IA? For example, spending time working up the wireframes might delay the whole process unless the IA work starts earlier than either the creative design and development work. Another design issue was one of segmenting creative work into time-boxed Sprints. The creative designer commented on the pressure they felt to create a unique design within just one week. Traditionally, our projects would start with the requirements gathering phase. During this phase, we gather user insights and stakeholders’ objectives, with IA work starting straight after. The IA would then create wireframes to demonstrate the structure of the site. Creative design would only start when all wireframes were created and signed off by the client. However, in this trial we started both wireframes and creative design simultaneously. This meant that creative design

6

Tzanidou, K. et al.

evolved more on-the-fly as the IA and creative designer were discussing and sketching out possible solutions.

6 Recommendations During the course of trialing Scrum, we dealt with questions relating to the IA and creative design roles. In dealing with these questions we make some recommendations for projects dealing with more than one design role: 1. Find the design guide. A conscious decision about who leads the design direction should be made. Answering this question in turn requires a decision on where the dependencies are between the different kinds of design that need to be coordinated (in our case, IA and creative design). On this project, both the IA and creative design roles started working on designs at the same point in time. Vague requirements at the start of our project, combined with having no designs that were signed off by the client, meant that there was some uncertainty about who was taking the lead. Although our solution did emerge, to avoid the initial uncertainty, we now recommend that the IA is started prior to the other activities and given enough time to stay ahead. The IA provides a coherent structure to the overall user experience that the creative designer and developers can follow. All user requirements should therefore be reflected in the wireframes first, before they are addressed by the creative designer. How far the IA should work ahead in our case would depend on the overall number of wireframes affected by the user requirements. We questioned whether creative design and IA should be separated in the first place. Based on our experience we have concluded that whether IA and creative design are separated or not will depend on the particular project’s needs. What is most important is that the IA should be in contact with the creative designer throughout the project to ensure that both roles are contributing to the overall user experience. 2. Plan for evaluating designs and incorporating the results. As time grew short, it became harder to avoid lowering the priority of design work. Assessment activities, such as user testing before launch, risked becoming a lower priority as the scoping changed throughout the Sprints and development aspects gained higher priority. We have made a point to include a Sprint for ‘quick and dirty’ user testing at least two weeks before launching. If a Sprint lasts two weeks then one week should be dedicated to user testing and one week dedicated to implementing changes based on the results. Careful planning of milestones before the start of the project and continuous assessment of the milestones throughout the project has proven effective in our subsequent Agile projects.

Design and Development in the “Agile Room”

7

7 Agile at Cimex: Post-trial Since completing the trial we have adapted our current practice in terms of how we communicate within our teams. The set-up of our building is such that it does not allow all staff to work on the same floor, let alone nearby each other. One of our biggest projects now is run in an Agile-like manner, despite not having a dedicated room for the team. We have replaced the location proximity with communication tools that are used throughout the day. We encourage frequent communication between designers and developers by encouraging them to use Skype and instant messaging. We also hold daily face-to-face meetings with the whole team. We continue to make use of Agile approaches on our projects and our Project Management team has used Agile methodologies on many or part of several projects now. We continue delivering functionality iteratively and incrementally, which enables us to be driven by our clients’ priorities. Our first increments of useful functionality are often delivered within a short period of time following the start of the project. Rather than being dependent on finalising designs and detailed architectures, we are confident that requirements, architectures and designs can successfully emerge throughout the project. Finally, we have found that new clients are motivated by our experience. We present our lessons learned from trialing Scrum to new clients as a case study in order to make them more aware of the flexibility an Agile project can provide.

8 Acknowledgments We would like to thank all our colleagues at Cimex who worked on the Agile project reported in this paper and all those who continuously make an effort to try and explore new methodologies that allow us to evolve and learn more about our capabilities and new goals we can set.