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