Get Agile. Pieter Jongerius
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 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.
fabrique.nl/getagile/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