Agile to User Experience How to do Scrum when User Experience is the objective Author: Rainer Dorau, macio GmbH Conference: embedded world conference 2013 26 28 February 2013, Messezentrum Nuremberg (NCC Ost) Presentation: 27 February 2013, 9:00 h Session 11, Management of Embedded System Design I ABSTRACT: Agile software engineering becomes more and more attractive for product developers, and Scrum is the most popular development process today. One huge challenge for a Scrum driven product development comes up when user experience is the topmost requirement for the product s user interface. How can the dev team ensure that the agile approach and its dynamism will not thwart all intentions to create a product with perfect usability and awesome user interface design? Critics say that Scrum is incompatible with usability and design goals. But we know it better and that is, what the presentation is about. Whereas classical Scrum concentrates on homogeneous teams made up of software developers only, a user-experience-oriented Scrum development introduces new actors to the roles. Usability professionals and user interface designers will join the team and focus on objectives that aim at goals beyond just technical performance. Their engagement will ensure a user-centered approach as well as industry leading design, their vision will anticipate the user experience of the product. If the Scrum set-up is adapted accordingly, the combination of usability and design can be made very productive and brought to life by the dev team. Great User Experience is not a mere phrase when designers and usability professionals stimulate a product development based on Scrum. Page 1 of 8
The Risk of Patchwork Design Scrum is a new way of thinking that leaves well-trodden paths behind. It is not only a new development process, but also a new project management framework. Scrum wants to replace rigid development processes like waterfall and opposes against inflexible procedures, but there is more. It introduces a new way of managing projects, it redefines the roles and the responsibility of the employees in a company, and it counts an uncompromising quality of the product among its highest goals. Here, we want to focus on the latter point. If you ask people Do you know about Scrum? you may get the answer Uh, yes, yes, isn t it this sprint thing? Cutting a project into slices of about two, three or four weeks seems to be an aspect of Scrum that is quite easy to comprehend, whereas other essential aspects like the different roles of the team members, the use of proprietory artifacts, and the time management require a deeper insight. So it s only natural that people, who never got in contact with agile development before, face this new project management framework with reserve and skepticism. One point of criticism says, the segmentation of the development process into several sprints causes fragmentation of concept which undermines the demand for great user experience (UX) on principle. This is a serious objection, and there is a deep truth in it. Due to the process schedule of Scrum the product is build sprint by sprint, feature by feature. It can t be denied that there is the risk of patchwork design : In focussing on product increments and discrete features you may lose sight of your product vision. How can you prevent that? The Holistic Approach Great designs and great user experiences require a development style that regards the user interface as a whole, as an essential and inseparable trait of the product. Otherwise things will not fit together and users will be confused about the unexpected behavior of the user interface. User interface design and user experience demand a holistic approach in product development there is no way round it. Speaking of a holistic approach means to focus on the overall product quality. Product quality is indivisible by nature. A product can be of high quality or of low quality, but never high and low at the same time. If there is a low feature, users will consider the overall Page 2 of 8
product quality as low, too. Which quality level has to be met during the development derives from the set of non-functional requirements. Among those design and user experience come first. Feature-related Quality Criteria and the Product Backlog The Scrum framework gives us some means to prevent us from shortcomings like fragmentation of concept and allows us to develop according to high-quality standards. The person of the Product Owner, who can be seen as the main quality manager in a Scrum project, is urged to have a keen eye on the created product increments. This person does a responsible job. She or he has to confirm that the increments comply to the given quality criteria as they are given in the Product Backlog. The Product Backlog is one of the most important artifacts of the Scrum framework. It holds the specification of all functional and non-functional requirements like design and user experience requirements that can be turned into tasks to be carried out by the development team. The Product Backlog is a very useful tool for the Product Owner and she or he is the person who owns it but it is build up in collaboration with the development team because the team will have to know the quality level and its definition that must be met. But does the Product Backlog help us to pursue a holistic approach? Does it escort us around the trap of patchwork design? Even for an experienced Product Owner it is hard to keep track and cross-check the overall consistency of the acceptance criteria in the Product Backlog, not least because the Product Backlog is an emergent artifact that will be specified in more detail during the project. The Product Backlog crystallizes more and more from sprint to sprint. So it may happen that you come to an ingenious solution for the usability of a feature in sprint 7, but already implemented a different solution for a similar feature in sprint 2 when sprint 7 was far away and still in an epic state. If you overlook the conceptual relationship between features of the same kind, the interaction between a human and your product will become inconsistent and unsuccessful. It is the Product Owner s task to define the acceptance criteria according to general quality requirements and to prevent that inconsistent acceptance criteria creep into the Product Backlog. But the Product Backlog alone will not guarantee consistency of design. As a project may become more and more complex, it also will get more difficult to conciliate the Product Backlog s acceptance criteria under the roof of general user experience re- Page 3 of 8
quirements. If you do not pay attention to this risk, you may encounter the following: If the acceptance criteria in your Product Backlog are not aligned with general rules, the development team may accomplish all tasks in accordance with the instructions, but nevertheless fail to build a consistent product with great user experience. This is a very dissatisfactory situation. Global Quality Criteria and the Definition of Done So, how can you do Scrum without losing a holistic approach? Besides the Product Backlog there is another important tool of the Scrum framework that can do a quite excellent job here: the so-called Definition of Done. We strongly recommend to make use of it thoroughly. The Definition of Done can be considered as a collection of general acceptance criteria that do no relate to particular items in the Product Backlog only, but applies to the product in its entirety and holds all global quality requirements. As such, those requirements do not have to be specified for each particular item in the Product Backlog explicitly. The Definition of Done describes global standards to be reached, so the development team will know when a task can be called done. The Definition of Done should be clear and visible for all team members, for example you may write it on cards and put it on the Board in the team room or even reserve a distinct area in the Product Backlog. Usually the Definition of Done is the result of a collaboration between Product Owner and development team but there may be external stakeholders, who will file non-functional global requirements, too. Designers and usability professionals may introduce design style guides and user experience guidelines as a basis for user interaction. Style guides and user experience guidelines are the most important artifacts in a Scrum project, when great user experience is the objective, though they are not mandatory elements of the Scrum framework. The development team may also introduce technical requirements to the Definition of Done like performance target values or coding conventions. Other artifacts that are owned by external stakeholders and shall be referenced in the Definition of Done can be legal documents, regulatory directives (e.g. ISO standards), and company guidelines. Last but not least the Definition of Done will reflect the contract between customer and the Scrum team. Instead of copying all global quality definitions from those documents into the Definition of Done, it may hold only a reference to such artifacts. Page 4 of 8
The Commitment to Quality A holistic approach can only be realized when every product increment is checked for its compliance with global quality requirements. Concerning user experience we have to check for existing design style guides and user experience guidelines. According to the Scrum framework the development team will have to commit itself to a certain amount of work at the beginning of a sprint and to follow the quality standards as specified in the Product Backlog and in the Definition of Done as well. At the end of the sprint, in the Sprint Review Meeting, the team will have to declare that the actual product increment still inherits its promised compliance. If the team fails to meet global user experience requirements as referenced in the Definition of Done, the tasks are not done. Done means a 100-percent match otherwise there is still work left to accomplish the task. Reasons for the failure may be discussed in the Sprint Review Meeting or Retrospective Meeting, but the Product Owner never may weaken the given quality criteria. And if you think about changing the Definition of Done in a later stage of your project, all increments that were classified done until then will have to be revised. Now you may imagine how important it is to have a clear vision of the product and its quality requirements before implementation starts. The same applies to legal and regulatory requirements for your product. If, for example, you need to declare the product s CE conformity, the development team will have to ensure every Sprint Review Meeting that the actual product increment will not lead to a conflict with the applicable directives of the European Union. If legal or regulatory requirements change during your project, you will have to check the conformity of the overall development state and redesign your product, if necessary. Like product quality legal and regulatory compliance is holistic by nature. Scrum Set-ups in Favor of Great User Experience If nothing like a design style guide or user experience guidelines, a concept of operations or a initial user interface design exist, you are advised to get down to work by building these artifacts first. There are several ways to setup your sprint scheme. While the Scrum framework defines the schedule of a sprint quite precisely, it gives you enough freedom to tailor the sprint Page 5 of 8
scheme according to your needs. I want to discuss three set-ups that leave plenty of space for user experience considerations to grow and quality definitions to settle. Do Exploration Sprints first If you do not feel sure of the usability and user experience of your product, wait with coding and start your project with UX exploration sprints. How many explorations sprints you need depends on the complexity and innovation of your product. Exploration sprints can result in a concept of operations, a proof of concept, user interface design, or even prototypes, supported by essential artifacts like user experience guidelines. After this preliminary work is done successfully, the coding can take over. Develop in Cycles Our first set-up smells a bit like waterfall exploration replaces the plan but then we take it as such. Well, we can refine this set-up. It would be great, if we had the possibility to re-adjust our user experience hypothesis after coding has started without going back to our start position. What we need are more UX exploration sprints at a later time. A good way to reconsider initial user interface concepts is to break up the development process into smaller cycles. Every cycle can start with an UX exploration sprint and proceed with, say, no more than three standard sprints. The horizon of the initial exploration sprint will be narrower than needed for the entire product, but sufficient enough for the tasks to be done in this cycle. This gives you the opportunity to focus on topics that are significant in the next few weeks or months, and it prevents you from planning an uncertain future. Pipeline your Project In Scrum literature you are warned: Don t do it. Don t do pipelining, unless there is no other chance. Unfortunately this warning is only practical in case of better alternatives. Not to make use of pipelining is a good advice for projects where everything is quite clear and everybody knows what the final product will be. But starting from scratch with a new and innovative product will never follow a standard way. When you have to do a lot of Page 6 of 8
conceptual work before the software engineers can go ahead, the standard way fails and pipelining shines up as a pretty smart proceeding. So, what is pipelining then? Pipelining means that you divide the group of developers into two or more teams, who pass their sprint results to another team to refine it. The pipeline turns out to be kind of supply chain where some teams deliver their work to other teams, whereas those have to wait for the work of precedent teams. Pipelining implies that the implementation of a potentially shippable increment, as the Scrum philosophy claims, can t be produced in only one sprint but will be prolonged over two or three sprints. A pipeline that uses three sprints may go like this: In the first sprint the UX team (made up of designers and usability professionals) lays down all necessary user experience and design basics; in the second sprint designs and prototypes are evaluated by the customer or a focus group; and in the third sprint the software engineers build the potentially shippable product increment. In this example software engineers wait for the go of the customer, and the customer waits for design prototypes made by the UX team. One advantage of such proceedings is that your customer will get quick evidence whether the product development is on the right track or not. Another advantage is that your UX team does not get unemployed in the mean time. When the design prototypes are examined by the customer, the UX team can proceed with their next tasks and so on. This way designers and usability professionals are always one or two sprints ahead of time. SUMMARY: User experience is a global quality criterion of a product and an essential part of the Definition of Done that holds global requirements of many different kinds, e.g. requirements for user interaction and user interface design. All development work that comes in touch with user experience considerations will have to reflect a respective user interface styleguide or user experience guidelines. A good way to establish a user-experience-oriented workflow is to tailor the sprint scheme and include UX exploration sprints at the beginning of the project, at the beginning of project cycles, or as a continuos work track in a set-up of collaborating teams. Page 7 of 8
ABOUT THE AUTHOR: Rainer Dorau looks back on 20 years of experience as user interface designer, project manager, and consultant for customers in the medical and production industry. At macio GmbH, Kiel, he focusses on interactive applications for machines and devices where usability, user experience, and leading user interface design is the objective. Rainer is awarded the designation Certified Scrum Product Owner by the Scrum Alliance, Inc. Besides his work as designer he enjoys to impart his knowledge to the community by giving presentations at conferences and writing articles and books on topics related to interaction design. Page 8 of 8