Get Agile

Scrum for ux, design & development

Pieter Jongerius

• Publisher: BIS Publishers
• Year: 2014
• ISBN:
  9789063693626
• Edition: 1
• Topic: Negocios y empresa
• Subtopic: Gestión de proyectos

Scrum is a project management method that dissolves boundaries and distributes responsibilities which in other methods have been protected for years. It is a radically different way of working: as many activities as possible take place at the same time, in the same room. Scrum is fast and delivers very high product quality at the same time. The book is a manual. It is aimed at everyone who works on interactive products in a design & development environment. It contains all of the basic information required for getting started with 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!

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 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 negotiation

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 AgileManifesto.org, 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 conte...