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