Читать книгу Get Agile - Pieter Jongerius - Страница 9

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