Get Agile. Pieter Jongerius

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.