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

If you have decided to start scrumming, it’s time to start thinking about your project setup. Who needs to be there? On which days? For how long? Which room will enhance collaboration between team members, with all of their different skills and characters?

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.

More about these topics in the following chapters. See the illustration below:

3.2 Sprint setup

So a project is divided into sprints. But what do these sprints look like? This is determined in the “sprint setup”. The sprint setup is, to a large extent, what determines the success of a project.

Fixed deliverable sprints: yes or no?

An important decision that must be made when starting up a project is whether the sprints will each have their own “deliverable” or if they will collectively deliver the final product. In most cases, the stories are simply divided over the sprints in a deliberate order. But sometimes it is more useful for each sprint to develop an appointed portion of the project. This ensures proper focus on the topic during the sprint, and strict timeboxing for the various components. The big disadvantage is that—in the event of progressive insight—you are not allowed to give more attention to a particular project section at the expense of another.

Combining design & development

In principle, we design and develop our products as one single Scrum team. This team can be made up of members from different organizations, such as ourselves, the customer, a development partner, etc.

Certain circumstances, however, may push us into alternative decisions. For example, we may find ourselves collaborating with a development partner who is unable to sprint with us. We must then involve them in our activities on a remote basis, as much as is feasible. We might do this by having the developer participate in Sprint 0, backlog grooming and possibly sprint planning meetings. Even in this type of situation, Scrum is a powerful tool for accomplishing good projects.

We use this method for some of our e-commerce projects. We first integrate strategy, design, and front-end development into the Scrum. Parallel to this, back-end logic such as system links, data models, and stock management might be handled remotely.

If you have the chance to genuinely include development, however, seize this opportunity! We now respectfully call a Scrum operation that incorporates all its related disciplines an “überScrum”—and we carry out most of our projects this way. This might for example be a website or an app with a CMS and workflow logic for customer contact. The Holy Grail of Agile design & development is to do design, front-end development and back-end development simultaneously in one room. But it’s not an easy feat to do this properly.

(For more about this, go to Chapter 6: “Sprinting Secrets”.)

What does a sprint look like?

A sprint is a portion of a project, a unit lasting several weeks. But what does a sprint look like in terms of planning? Over the years we have developed a few rules of thumb:

♦ A project has a fixed sprinting pattern. The number of days and the specific days each week are always the same. Demos and usability tests are planned in advance.

♦ There are usually three or four sprint days per week. This allows for other activities and part-time work. For many customers, this is also a comfortable pace. If top speed is required, there is the option of five sprint days per week—which is pretty tough for the team as well as the client, but can certainly be worth it! On the other hand, scheduling a mere two sprint days per week is not advised. The team doesn’t manage to get up to speed and must constantly get back into the status of the project.

♦ It’s a good idea to match your Scrum week with the calendar week. So, start a sprint on Monday and do the demo on Friday (or Thursday, or Wednesday). This is the best way to get that feeling of really ending a sprint in one week, and starting fresh with a new one the next week.

♦ A sprint usually lasts two weeks. This pace ensures fast enough feedback from demos and the retrospective. In the event of longer projects (three months or longer), you could opt for a three-week sprint. Three weeks may also be better for überScrums that are developing innovative products. This gives the team more time to iterate within the sprint.

♦ Sprint 0 may differ from the other sprints in terms of scope and planning. The estimated time for this sprint is that, per team member, there are as many days as there are sprints in the project. Does the project last for five sprints? If so, Sprint 0 lasts five days, spread over two weeks. In Sprint 0 you may decide to allocate more time to the discipline leads than to the juniors.

♦ Contrary to popular belief, the entire Scrum team does not have to be working on the project on all of the Scrum days. Often, development requires more workdays than design. You may decide to have four or five days of development, and three or four days of design. Do try to have the team seated together, even on days when designers may be working on other projects.

3.3 Flexible scope

Be like water: In Scrum your agency is constantly being exposed to all kinds of influences: your client’s whims, ever-changing requirements and demands, and pleasant and unpleasant surprises across the board. Don’t try to foresee them—but accept them and deal with them in an intelligent and flexible manner, thus optimizing the product.

As Scrum must lead to a final result within a set timeframe (a certain number of sprints), the Be like water principle has an important effect:

The scope is flexible—

For many clients this takes a lot of getting used to. The design & development team does not promise there will be 138 features; it promises a product that will meet the client’s vision and goals. It keeps track of this progress on a day-to-day basis, and the feedback loops are very short.

In exchange for commitment, the team gets freedom. This freedom is not unconditional: in exchange for flexible scope, the team grants all power over the product backlog to the product owner.

To put pressure on the project, the team offers ideas and inspiration for a higher level of functionality than actually fits the project. At the same time, it protects the quality of each component delivered. It is up to the product owner to set priorities on a continuous basis.

3.4 How many sprints do you need?

Before the project commences you would like to make a rough estimate of the costs, and thus the number of sprints. Like in waterfall, you can determine the total number of sprints by estimating the amount of time required to develop a Minimal Viable Product (MVP), on the grounds of the preliminary questions or specifications provided by the client.