Get Agile!: Scrum for UX, Design & Development
  • Alternative view 1 of Get Agile!: Scrum for UX, Design & Development
  • Alternative view 2 of Get Agile!: Scrum for UX, Design & Development
  • Alternative view 3 of Get Agile!: Scrum for UX, Design & Development
<Previous >Next

Get Agile!: Scrum for UX, Design & Development

by Pieter Jongerius

Scrum is a project management tool enabling people with different skill sets to strategize together. This manual is aimed at everyone who works on interactive products in a design and development environment. It contains all of the basic information required for getting started with the project management method Scrum, but also offers a number of in-depth chapters


Scrum is a project management tool enabling people with different skill sets to strategize together. This manual is aimed at everyone who works on interactive products in a design and development environment. It contains all of the basic information required for getting started with the project management method Scrum, but also offers a number of in-depth chapters looking at topics which even the most experienced Scrummers have trouble with on a daily basis. If you are experienced, you will find the advanced tips and tricks useful. If you are just considering Scrum, this book will most certainly get you enthusiastic.

Product Details

BIS Publishers
Publication date:
Sales rank:
Product dimensions:
6.20(w) x 8.20(h) x 0.70(d)

Read an Excerpt

Get Agile!

By Pieter Jongerius

BIS Publishers

Copyright © 2012 BIS Publishers
All rights reserved.
ISBN: 978-90-6369-302-2



by Pieter Jongerius

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.


What, Why, When

by Pieter Jongerius

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.

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 are uncovering better ways to develop software by doing it and helping others to do it. Through this work we have come to value:

Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiationv Responding to change
over following a plan.

While the italic items of this list carry value, we value the bold items more.

A great deal has been said and written about the principles on which Agile methods should be based. We recommend that you decide for yourself which ones work best for you.

Our own selection — also listed on the inside cover of this book — are as follows:

End users first

Scrum is not about the team. It is not about the client. It is not even about the product. It is about being relevant to the end-users.

Freedom vs. commitment

Scrum offers freedom in exchange for commitment. This goes for the organization, the team members, and the client. Welcome change — but also, kill the monster while it's small.

Eliminate waste

Direct and ad-hoc communication replaces the costly overhead of time spent on meetings, documentation, and re-workings. Prioritization eliminates the incorporation of waste into the product itself.

Self-propelled team

No. A team doesn't actually have to manage and organize itself — as long as it's open, energetic, and self-motivated, and you don't have to drag it around wherever it needs to go.

Timebox everything

As in real life, we always want more, and we can't always have it. Timeboxing prevents us from dwelling in dreams: the clock ticks, and the team moves on.

Shippable product

Any Sprint result should be a product or product part that's ready-to-deploy — with no fake copy, no blocking issues, no black boxes or white spaces.

[Adapted from, Lean Software Development (Poppendieck 2003) and Bruce Lee.]

2.3 What is Scrum?

One of the abovementioned lightweight methods was Scrum. At first tentatively referred to as the "rugby" approach, Scrum developed into a well-defined method in the early 1990s, due to the collaboration of people such as Ken Schwaber and Jeff Sutherland.

The principles of Agile apply to Scrum. Scrum dissolves boundaries and distributes responsibilities, which, in waterfall, are protected. A radically different way of working, Scrum has as many activities as possible taking place simultaneously in one room. It focuses on efficiently preparing product components for publication, going from first sketch to implementation in blocks of time lasting several weeks.

A few smart rules ensure that this process is not only fast, but also quite controlled.

The basic concept behind Scrum is that your activities are based on a fixed overall vision, rather than fixed goals and content. Because the environment is constantly changing, Scrum does not posit a detailed "master plan", allowing final results to come about organically. This way, you avoid ending up with a final product that — while meeting earlier specifications — unfortunately no longer meets the end users' actual needs.

In 2008 we applied Scrum to our overall design and development process — adding, most importantly, a multi-disciplinary component. This allows for many disciplines to be applied to the same project at once. With, for instance, UX designers, visual designers, developers, and editors working together, Scrum ensures this process remains clear and efficient.

We owe many thanks to Henrik Kniberg and his fantastic, downloadable book, Scrum & XP from the Trenches.

2.4 When to Scrum

Advantages for the client

It is actually quite strange that agencies often settle for relatively little customer contact when designing and developing a complicated project. On waterfall projects in particular, an entire team often gets to work on the basis of a handful of documents and a briefing session lasting merely a few hours.

Scrum, however, has the client play an important role. The direct client, the product owner is at the core of the team and has the important responsibility of guiding the team and making decisions. To this end, he or she works with the team several days a week in the team room.

Scrum lets you see just how useful it is to take ongoing advantage of your client's customer and market knowledge. And as a nice bonus: there's no more need for those awful foam-board presentations — have we hit the mark yet? — that are so often just a shot in the dark.

This great change in the distance between agency and client is something everyone has to get used to, but the impact is huge.

Scrum offers clients three significant advantages:

* Short time to market — Scrum is fast. In our experience, turnaround times are about half those achieved with waterfall.

* Quality — Scrum encourages a feeling of responsibility for all people involved and improves communication among disciplines. Thus the team becomes much more motivated, and big surprises are prevented. Scrum also allows for far more control over the final result. This all has a marvelous effect on the final quality of the agreed deliverables.

* Delivery assurance — Progress monitoring and evaluation are deeply embedded in the Scrum process. Therefore a Scrum team is able to guarantee that a product will be ready within a limited, short timeframe.

Scrum is useful ...

* If your projects require a lot of reworking: When progressive insight occurs only in later phases, reworking becomes necessary. By bringing these phases much closer together, progressive insight is gained much earlier. The loops become shorter, and there is less loss.

* If projects often run over: There are hundreds of reasons why waterfall projects may run over. But most common ones are insufficient progress monitoring, paired with a limited learning capacity built into project organization. Scrum deals rigorously with both.

* If the different disciplines do not understand and/or blame one another: Putting everyone in a single room means that people really have to work with one another. Less physical distance automatically leads to less mental distance. We're in this together!

* If designers design things that are difficult to build: We have all heard of artists who don't want to make allowances. And while the magic of design is an important part of the creative process, at some point we all have to come back down to earth. Scrum (ultimately) makes this happen.

* If developers encounter problems implementing the delivered design: There may be many reasons for this. The design may be too outrageous. The scope or quality of the design may be insufficient. The technical or functional preconditions may be unclear. But the solution is often the same: bring people together and thus improve communication.

* If people in your organization slow projects down by constantly having their say: Scrum provides focus. Those who are not part of the process realize that it's all systems go — for real. And this requires a certain level of autonomy. There's no stopping the Scrum train!

Scrum provides ...

* A foundation for your product: With the client as part of the team, you have a greater amount of useful information to base your work on. It is all about the "bandwidth".

* Adaptability: With the project not entirely fixed in advance, and with an inspection and control system in place, you can make better use of ongoing progressive insight — regardless of whether this insight comes from the client or another member of the team.

* Visibility: Scrum makes your process, people, and motivation very transparent. Any pleasant surprises? They can be celebrated with your client. Any disappointments? Then you and your client can get through those together — and enhance your mutual understanding in the process.

2.5 When not to Scrum

When Scrum works well, it releases you from much of the overhead you may be used to with waterfall projects. This makes for a most enjoyable process, whereby common sense, craftsmanship and passion for content can surface. Commitment will be rewarded.

Nevertheless, Scrum is not for everyone. In some environments and for certain clients, Scrum is too fast, too isolating, or too centered on informal collaboration. Even in these situations, Scrum needn't be dismissed entirely. Setting up a Scrum board, for example, is always a good way to get an overall picture. It all comes down to your organization's ability to implement the method for their particular purposes.

Scrum is not useful ...

* If your project requires a lot of thinking and realization: Scrum is speedy and aimed at "getting things done". Depending on the task or the person, Scrum can be too speedy. It's virtually impossible to let an idea simmer for a week or so, and then go back to it. But it is always possible to find room for brainstorming, ideation, radical concepts, and sparkling innovation.

* If the quality or seniority of team members is below par: Scrum is all about improvising, prioritizing, and making choices. It takes quality and experience to do all of this efficiently.

* If the client has difficulty making decisions: In waterfall, a client who hesitates causes delays. Parts of the product, for instance, may not be approved. In Scrum this would lead to an uncontrolled process, whereby all kinds of things get done — but none of them would be based on correct decisions. A good Scrum team will spot this and not irrationally carry on sprinting.

* If a client's democratic sign-off policy cannot be breached: If clients are extremely democratic or have unclear decision making structures, there is a chance that the client's team representative, or product owner, will receive insufficient mandates. When every little detail has to be discussed with the back office, the sprint soon slows down.

* If the client or supplier has a very formal culture: When team members are tied to extensive documentation or 'Def' deliverables between disciplines, it is at the expense of the parallel nature of sprints. The ability to continue working on semi-finished products, premises, and presumptions is what makes Scrum so efficient.

So ...

Now you know how Scrum came about, what its advantages are, and how we have adapted it for the design & development world. If you decide to start Scrumming, move on to the next chapter: How to set up a project.

Happy Scrumming!


How to set up a project

by Anna Offermans

3.1 A project is made up of sprints

This book refers mainly to interactive media projects. These projects have an identifiable, often strategic beginning. And being within the interactive media domain, they are multidisciplinary in nature, with a variety of different roles required to accomplish the product.

A project must do a number of sprints before it can go live. A sprint is a unit of several weeks, during which a portion of the project is carried out. Sprints can also be used when a project is already live, in order to make step-by-step improvements to the product. In the world of Scrum, they are then often no longer referred to as sprints, but "iterations".

The entire project is divided into "user stories". A story is an identifiable, more or less independent unit. For example; "as a user, I want to be surprised with new recipes". The collection of all the stories relating to the project as a whole is called the "product backlog", the list of things we want to realize. During a sprint, several different stories are realized; the number depends on the size of the stories. Sprints have tight deadlines, ambitious goals, and last two to three weeks. Running over is not an option. Adjustments however, are allowed to be made.


Excerpted from Get Agile! by Pieter Jongerius. Copyright © 2012 BIS Publishers. Excerpted by permission of BIS Publishers.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Meet the Author

Pieter Jongerius (author and editor-in-chief) is a partner at the Dutch design agency Fabrique. Pieter has been a pioneer of using Scrum in design and development projects. He was involved in the Scrum projects for clients in retail and fashion amongst others and has written a number of leading articles about Scrum.

Anna Offermans, Anton Vanhoucke, Patrick Sanwikarja and Jeroen van Geel (co-authors), are all senior Scrum masters at Fabrique and have a professional background as interaction designer or director. They have had many years of Scrum experience doing projects for a wide range of industries such as financial, retail, education, and transport.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >