How to adapt the 12 principles of Scrum for product development

In order to carry out projects, we are all used to proceed according to the so-called waterfall model: Once one step has been completed, the team sets about implementing the next one. This method has three advantages:

• The different project phases are clearly defined.
• Planning and control are simple.
• The costs and scope of the project can be clearly estimated in advance.

These advantages apply at least when it is already clear at the beginning how the project should look exactly. However, we live in turbulent times and the speed of change is constantly increasing. Even if a project only takes a few months, it is possible that the framework conditions, and thus the requirements, have changed. The waterfall model is hardly suitable to deal with such changes; it is much too static for that.

How agile project management works

Agile project management methods such as Scrum are much more flexible. Of course, the mechanics of Scrum can be displayed graphically on one page. If you want to learn more about the project management method, you will find a guideline that has been continuously developed by the Scrum developers here. 

Relay versus rugby team

The two Scrum ancestors Hirotaka Takeuchi and Ikujiro Nonaka compared the classic development process with a relay race. Each runner has the task of covering a part of the way and then passing the baton on to the next runner. Scrum, on the other hand, follows a rugby approach: a team covers the entire distance together, but plays the ball flexibly back and forth.

To stick with this comparison with sport: In relay racing, neither the knowledge nor creativity of the individual runner is required: he has the order to cover the distance from A to B as quickly as possible, so to speak. Rugby is different. Here each individual team member must know their own strategy, implement it according to the circumstances and react to every change. On the one hand, the entire potential of each individual is in demand and on the other hand, everyone has the necessary freedom to act on their own initiative.

A Manifesto for Agile Project Management

By the way, the comparison to rugby is no accident. Scrum is not an acronym, but stands for an orderly crowd in this very sport. To ensure that this "crowd" also leads to results, those involved in the process must follow certain principles. By the way, these basic rules come from the software industry: In 2001, 17 experts for alternative project management methods withdrew for three days from a ski hut in the US state of Utah and developed the "agile manifesto". The three founders of Scrum Ken Schwaber, Mike Beedle and Jeff Sutherland were also part of this group. This manifesto therefore applies to Scrum and can be summarized in four points:

1. Individuals and interactions are more than processes and tools
2. Functioning software is more important than comprehensive documentation
3. Cooperation with the customer is to be valued more highly than contract negotiation
4. Responding to change is more important than following a plan

The 12 principles of the agile manifesto

This manifesto is based on 12 basic principles. Because the "agile manifesto" was originally intended for the development of software, these rules also refer to it in the original. However, Scrum is suitable for any other development process. However, you should adapt these rules to your needs before using them. This process is called "Scrumbut" (We use scrum, but...). The 12 rules in their original version are as follows and have been adapted by us for product development:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
   However, if the products are to be developed, you should set the early and continuous delivery of milestones, ideally MVPs (Minimal Viable Products) as the goal after each sprint. The requirements for the MVP change depending on the progress of the project. The core statement of rule number one remains the same: You should be able to show your customer tangible progress as quickly as possible.
2. Changes in requirements are also welcome late in development. Agile processes use changes for the competitive advantage of the customer.
3. Deliver working software regularly within a few weeks or months, preferring the shorter time span.
   If the products are MVPs, then this rule should apply to MVPs.
4. Experts and developers must work together on a daily basis during the project.
   Of course, you can adapt this rule to the time options of your project team. If a Scrum project is not the team's only task, then it also works to schedule one or more fixed weekdays for work. It is important that the experts and developers work together regularly and that the subsequent coordination takes place regularly in the stand-up meeting.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to do the job.
6. The most efficient and effective way to communicate information to and within a development team is face-to-face communication.
   With teams whose members are in different locations, this requirement is not easy to meet. This is where video conferencing solutions can help. Providing such is the task of the Scrum Master.
7. Functioning software is the most important measure of progress.
   For products, MVPs are of course meant here. It is best to coordinate with the customer in advance how you present your progress. Especially in the first sprints concepts in the form of sketches are allowed.
8. Agile processes promote sustainable development. Clients, developers and users should be able to maintain a steady pace for an unlimited period of time.
9. Constant attention to technical excellence and good design promotes agility.
10. Simplicity -- the art of maximizing the amount of work not done (because it is unnecessary) -- is essential.
11. The best architectures, requirements and designs, and in the case of products also MVPs and concepts, are created by self-organized teams.
12. At regular intervals, the team reflects on how it can become more effective and adapts its behaviour accordingly.

One of the co-founders of Scrum, Jeff Sutherland, describes in his book on the project management method, how the double work can be achieved in half the time by following the rules. The Viennese inbound marketing agency TakeOffPR tried the method after reading the volume in a self-experiment and does not want to do without it anymore. Why this is so and how the new project management method was implemented is described by agency manager Martin Bredl in a blog post. His advice is to simply try Scrum and not get lost in the increasingly complex set of rules. Bredl has also adapted the rules and regulations to the needs of his agency. After all, Scrum should not become an end in itself.

Conclusion: How to adapt the 12 principles of Scrum for product development

To develop something new, you need a plan. The more people involved in its implementation, the more complex it becomes. It is extremely important that all parties involved outline the goal as precisely as possible before the first step of the common path is taken. In modern business life, however, it can quickly happen that the previously defined goal loses relevance because the general conditions have changed. Finding a quick enough response to changes in the environment is one of our special strengths. Otherwise we would not have been the "crowning glory of creation" and would probably have died out long ago. The ever more complex challenges of our time require ever more creativity and know-how. There is actually enough of this resource in all our minds. Classical project management methods such as the waterfall method only use the brain lard of a few and degrades the vast majority to vicarious agents. Agile project management in turn tries to tap the full potential of all team members. That's why Scrum and Co can probably achieve much better results. Besides, it should make working much more fun, as one hears.