Get Agile: Scrum for ux, design & development

Preface

When we established Fabrique in 1992, we had been freshly trained at the TU Delft in design methods where we worked step by step from a design brief towards a product. This was a serial approach which we nowadays call the waterfall method: a method that provides a guideline and guarantees results, especially in static and straightforward situations.

In the course of the years, there have been many changes in our work environment. The dynamics in developing digital media, in particular, have increased to a point where a classical approach will no longer do. For one thing, our customers are asking for shorter lead times. Moreover, they increasingly have pertinent expertise themselves, and it is therefore very useful and desirable for them to actively participate instead of just placing an order. On a regular basis, projects are too large for controlled development and documentation, while at the same time keeping up the pace, with conventional methods. And our customers are not only demanding the final result; they also want influence on the journey towards the goal. On top of all that, we are working in a multidisciplinary environment where strategists, interaction and visual designers, copywriters and programmers want to work together. Therefore, it was time to think about a new approach.

In 2008, we got started on Scrum. Through trial and error, we found out that this method offers a very good response to the changing demand in our design practice as well. Since 2008, at Fabrique, through experimentation, evaluation and finetuning we expanded the Scrum method from a software development tool to an integral innovation method in the field of digital media. All this time we were driven by our — admittedly somewhat geeky fascination for the design process.

So, is Scrum the Holy Grail of digital media development? Of course not. Scrum bears certain risks, and the decision to use it must be carefully considered. This aspect is covered in-depth in the book as well.

A book?

Yes, a book. Scrum is a very physical method. You cannot miss it if people are scrumming somewhere: there will be post-its and flip-over sheets all over the place. Therefore, we found it very appropriate to bundle all of our knowledge and experience in an old-fashioned book — another physical object that you can soon have lying about in your Scrum rooms.

We wish you success!

Gert Hans Berghuis

Managing Partner, Fabrique

Fabrique, a multidisciplinary agency, has scrummed for 48 national and international clients since 2008. Our Scrum experience consists of numerous projects for a wide range of industries such as finance, retail, fashion, education, and transport. With 76 Scrum Masters, designers, developers, copywriters, directors and strategists, we scrummed for 56,619 hours, together with product owners, photographers, content managers, technical partners, and stakeholders, in 264 sprints. In that time, we completed 2,361 stories with a total of 30,710 tasks. 30,711… 30,712… 30,713… and counting…

Agile design & development, and Scrum, mean the return of common sense. In Agile, future quality is more important than past decisions. Trust is more important than documentation. Freedom in exchange for commitment.

With Scrum, you as the design & development team invite the client into your territory. Together you will develop the insights and products which will help his business grow. You will be open to his ideas and you will be required to expose many different facets of yourself. Together you will overcome disappointments and celebrate victories. Selling Scrum is selling an experience. Scrum is never boring!

Due to the set rules in Scrum projects, dilemmas come to light at top speed: break off or give a bit more time? Discuss now or let things simmer? Dig into it or make assumptions? This requires the very best from teams. In this book the main steps and issues are discussed, and team members tell us about their experience:

2. What, Why, When - This chapter discusses the history and philosophy of Scrum, the reasons for applying it, but also possible reasons why not to use Scrum.

3. How to set up a project - If you’ve decided to scrum, you will want to know what the team has to look like, how much time it costs, what the structure of Scrum projects is and what the requirements are in terms of organization and facilities.

4. Sprint 0 - This first special stage provides base and defines direction. How do you get to grips with the assignment? How do you get the right ambition in the team? The team will start ideation, do basic design and set up technical architecture. It will divide the project into manageable chunks.

5. Go sprint! - This is the real deal. Kick-offs, progress monitoring, evaluations and more. This chapter focuses on the daily practice of the Scrum.

6. Sprinting Secrets - Now that the basics of Scrum are covered, we can elaborate on some of our real secrets: how can you simultaneously design and develop? How do you maintain or enhance your creativity? How do you deal with difficult product owners?

7. Troubleshooting - Like in any good handbook there is a problem solving section. The most common problems are briefly described and we offer possible solutions.

8. Meet the Team - Eight team members from different disciplines (director, interaction designer, visual designer, developer, Scrum Master, project manager, client) each answer important questions about their role, how Scrum has helped them, about the dangers, etc. We offer links to five minute video interviews online.

9. Glossary - Yes, Scrum uses a lot of slang terms. Here are the most important ones.

Scrum is one of the most difficult processes to master. It all comes down to the ability to improvise, craftmanship, and authentic hard-won team building (so not the semi-survival blindfolded paintball-on-a-ledge surrogate teambuilding that you can buy just anywhere). Take this handbook with you wherever you scrum, you will need it!

In the next chapter we will start with the first step: deciding whether to use Scrum or not.

Everyone has different reasons for wanting to scrum. Maybe your project turnaround times seem too long. Maybe you are fed up with unworkable specifications—or maybe you’d just like to work with post-its a bit more.

There are many different reasons why teams and organizations want to Scrum. There are also situations, however, in which Scrum won’t work. This chapter looks at the main ones.

2.1 It all began with waterfall

In waterfall, various disciplines act step by step like a kind of relay race: strategy, interaction design, visual design and development. We worked with the waterfall model for many years and sometimes still do.

For many projects, however, the step-by-step process is problematic. That’s because in practice, the aims and functionality you wish to achieve are influenced by things that may only become apparent once the project is underway. Some things occur due to the nature of the work: a developer realizes that a certain interaction is very tricky to build; or an editor notices that the design doesn’t quite meet communication requirements.

It is also just as common for part of the assignment to change. New business rules may crop up. Company strategy may be altered. Some of the designated photographs may prove to be unsuitable.

In waterfall, this progressive insight leads to delays due to the reviewing and reworking of previous deliverables, such as requirements, flows, and annotated wireframes. Scrum eliminates all this by enabling disciplines to interact right from the start; by leaving room for new insights; and, by eliminating intermediate deliverables as much as possible.

The Waiting Developer

2.2 What is Agile?

The terms Agile and Scrum have mainly been used to refer to software development methods. In 2008, however, we discovered that the Agile approach, with Scrum as a method, is not only suitable for software development. It is also extremely suitable for improving the entire process of concept, design, and development. As one of the pioneers of this approach, we are delighted to see more and more people embrace this idea.

When using Agile methods, accommodating change is more important than following a strict plan.

Agile is a way of thinking. Scrum is a method that was developed in line with this way of thinking. Agile came about in the seventies as a group of adaptive software development methods. It gained wide recognition in the nineties under the name lightweight methods.

Since 2001 these methods have become known as Agile methods, after the groundbreaking Manifesto for Agile Software Development, which was published that year.

Drawn up by a group of visionary software developers, this manifesto is brief enough to include here:

We