Scrum - Flexible Agile Project Man­age­ment

When a team starts a project, they don’t just dive straight into work – most projects require project or product man­age­ment first. The agile approach is common practice in many companies today. The focus is on flexible working methods, in­cre­ment­al de­vel­op­ments and trans­par­ent processes. In the sphere of agile project man­age­ment, the term “Scrum” is becoming in­creas­ingly well known. Ori­gin­ally intended for software de­vel­op­ment, the model has also become popular in many other in­dus­tries. In this article, we explain what exactly this buzzword entails.

Scrum dates back as far as the 80s, but it has been around in its present form since 1995. It was then that Ken Schwaber and Jeff Suth­er­land teamed up to publish a paper, the “Scrum Guide.” They wanted to make work more pro­duct­ive and at the same time introduce as few reg­u­la­tions as possible to avoid limiting cre­ativ­ity.

To make this possible, Scrum defined a framework that could easily be applied to various situ­ations. This is done with the aim of con­tinu­ously improving both the way we work and the product or service itself. Parts of the framework are cat­egor­ised into roles, events, artefacts, and rules. Within these limits, Scrum teams should be able to achieve results as ef­fi­ciently as possible, providing the customer with the best possible product. Customers, clients, and users play an important role at Scrum: the de­vel­op­ment of the product is spe­cific­ally tailored to their re­quire­ments.

With regards to working with Scrum, there are two keywords that play a very important role:

• Iterative: With Scrum, a product is con­stantly evolving and per­form­ing re­peatedly. The process is cyclical: it starts with planning and de­vel­op­ment, then testing and eval­u­at­ing, and finally it comes back to the planning phase. So, the Scrum meth­od­o­logy is not only as­so­ci­ated with the initial pro­duc­tion, but also with future de­vel­op­ments.
• In­cre­ment­al: Scrum is based on the idea that a product is created step-by-step. Each step rep­res­ents in­ter­me­di­ate goals. This method is a departure from a way of working toward one single goal at the end of de­vel­op­ment. To achieve greater flex­ib­il­ity, large projects are divided into several smaller ones.

If you combine the two ap­proaches described above, the result is an iterative-in­cre­ment­al approach, which implies both a constant, gradual de­vel­op­ment, and step-by-step checks and it­er­a­tions. On the one hand, this approach makes the process more trans­par­ent and efficient, since checks are planned more fre­quently, and on the other hand, the quality of the product is also improved, since its func­tion­al­ity is con­tinu­ously tested.

Scrum was ori­gin­ally intended for agile software de­vel­op­ment; de­velopers rely on Agile Scrum to con­tin­ously improve their work on programs. But it is also a suitable model for other products – for example, with the pro­duc­tion of hardware. At the end of a Scrum project, it’s not com­pletely necessary to have a physical product – every result-oriented project can benefit from the Scrum meth­od­o­logy. For example, the model is also suc­cess­fully used for the or­gan­isa­tion of marketing teams or ad­min­is­trat­ive bodies, and to develop services.

The starting point of Scrum is always with small teams, although “small” is a relative term. For larger work groups, however, the flexible model is less suitable, but there is always the option of dividing these up into smaller groups. Scrum is also ideal for net­work­ing teams. The framework places great emphasis on teamwork: within a Scrum team, each in­di­vidu­al member should bring their own skillset to the table.

Scrum is not a fixed method or concrete working technique, but rather a framework that offers the teams points of reference for their work process. There are certain roles, events, and artefacts within this framework.

Within a Scrum team, there are three fixed roles: the team, the product owner, and the Scrum master. The team are the actual de­velopers of the product. The group is set up in such a way that it can organise itself and determine how they want to reach an agreed goal. At Scrum, there are no hier­arch­ies within a team. While it goes without saying that each employee has his or her own area of re­spons­ib­il­ity within the team, everyone has to account for the product in the final review.

The size of the team is fixed: you should be set up so that you can act quickly and flexibly, but also remain efficient. Aim for a medium-sized team: not too big and not too small. Schwaber and Suth­er­land recommend between three and nine members per team.

The product owner is re­spons­ible for the quality of a product and the work. This person takes on a control function. The product owner organises a product backlog, a list that defines the re­quire­ments for the project (you can find out more about product backlog in the “Scrum artefacts” section below. One of the tasks of the product owner is to put the goals in order and document them. The product owner plays a deciding role: while the teams them­selves set out how they achieve the goals es­tab­lished in the backlog, es­tab­lish­ing the goals is done at the product owner’s dis­cre­tion. To ensure maximum pro­ductiv­ity, the team must trust the decisions of the product owner. Nev­er­the­less, there is no leader with Scrum: both the product owner and the team have different focus areas and are decisive in their own area. Just as the team does not question the backlog, the product owner does not interfere in the de­vel­op­ment process.

In com­par­is­on to the other roles, the Scrum master functions as a sort of mediator. They are re­spons­ible for in­teg­rat­ing and enforcing the workflow. That means that this role is re­spons­ible for the overall or­gan­isa­tion of the Scrum team. This person also organises and moderates meetings. Ad­di­tion­ally, the Scrum master assists both the team and the product owner, but they never interfere in the actual de­vel­op­ment process. Their function is merely to simplify the work processes for all employees involved in pro­duc­tion, while in­creas­ing pro­ductiv­ity and cre­ativ­ity.

As a contact person, the Scrum master ensures that everyone involved un­der­stands the processes correctly. They give tips regarding the backlog or the or­gan­isa­tion of the team, and try to settle any issues that may arise. The Scrum master has a similar function to a coach. It is essential for this person to be very familiar with the framework. It’s even possible to get certified as a Scrum master; several cer­ti­fic­a­tion bodies offer cor­res­pond­ing training courses. Both the Scrum Alliance and Scrum.org were founded by Ken Schwaber, and offer the “Certified Scrum Master” and the “Pro­fes­sion­al Scrum Master” cer­ti­fic­ates.

If you organise workflows according to the Scrum principle, there are certain events that occur regularly. Since Scrum is an iterative process, the work is carried out in re­pet­it­ive cycles. Each event takes place again with each re­pe­ti­tion. The frequency of Scrum events means that there are hardly ever any un­sched­uled meetings. All events have a fixed timeframe.

The cycle itself is known as a “sprint.” This describes the de­vel­op­ment phase. At the end of a sprint, the de­vel­op­ment team delivers a finished product increment. This means, that the de­vel­op­ment must have led to a product that can po­ten­tially be delivered. Each sprint has a clear mission that is completed at the end of a project. The timeframe for a sprint is de­term­ined in advance, but should not exceed 30 days. When de­term­in­ing the timespan, the following factors should be taken into account: a sprint can’t be extended or shortened, and the other project sprints should have the same duration.

Sprints are de­lib­er­ately kept short so that the for­mu­la­tion of goals is not too com­plic­ated. The short duration also ensures that progress can be reviewed at the end of each month. Only in a few ex­cep­tion­al cases may a product owner cancel a sprint – and only the product owner. It’s possible to do so if, for example, the company’s goal has changed and the original goal no longer needs to be achieved. In principle, however, sprints shouldn’t be cancelled, as this reduces pro­ductiv­ity.

A sprint begins with sprint planning. All roles within a Scrum team should be involved in this phase. During a meeting, par­ti­cipants discuss the upcoming product increment – what should each increment entail and how should the goal be achieved. The meeting should last no more than eight hours. The starting point for the planning phase should be the product backlog. The de­vel­op­ment team and the product owner sit down together and agree on which goals should be achieved in the coming month. The de­vel­op­ment team then discusses how the tasks should be completed. At the end of the meeting, the de­velopers should discuss the plan together with the product owner and the Scrum master.

Within the sprint, a Scrum takes place every day. This occurs at the same time and the same place each day, to organise the company’s effort. During this 15-minute meeting, the developer team goes through the out­stand­ing tasks for the day and the progress made the previous day. The de­velopers also assess the general progress of the project, including the progress made with backlog entries. The daily com­par­is­on ensures that all parties involved remain focused on their goals, which ul­ti­mately results in increased pro­ductiv­ity.

The Scrum master is re­spons­ible for ensuring that the daily Scrum takes place, while the de­velopers are re­spons­ible them­selves for the progress of the meetings. They decide which items are discussed in each meeting. As long as the content is about achieving the sprint goal and the 15 minutes are not exceeded, the Scrum master does not interfere, and ensures that no one else in­ter­feres the de­velopers during the daily Scrum.

When the sprint has come to an end, a sprint review follows. This process analyses the product increment. The results are evaluated together with people that aren’t part of the Scrum team but still have an interest in the product, such as company owners or customers (col­lect­ively called stake­hold­ers at Scrum). Ad­di­tion­ally, the work processes are discussed and the various problems or chal­lenges that arose during de­vel­op­ment are shared. This has an impact on the further planning, because the product owner uses the op­por­tun­ity to respond to the progress of the backlog. The findings of the sprint influence the outlook for future per­form­ance.

The re­spect­ive market situation also has an influence on the backlog. Par­tic­u­larly with long-term projects, pri­or­it­ies can shift and budgets can change. Such topics will also be con­sidered in the sprint review and will change the future approach. For a month-long sprint, no more than four hours are required for the review.

The sprint review is followed by another review, the sprint ret­ro­spect­ive. The entire Scrum team – including the product owner and scrum master, but not the stake­hold­ers – sit together for a feedback round that should last no longer than three hours. While the review focuses primarily on the product and the progress of the product, the ret­ro­spect­ive is mostly about teamwork. The aim of the second review is to improve the team’s ability to work together and to smoothen out any internal problems. As soon as a sprint ends, the planning phase of the next one begins.

Items that play an important role within Scrum are called artefacts. This includes the likes of product backlogs, sprint backlogs, and the completed in­cre­ments.

Trans­par­ency is an important element of Scrum. Everyone involved should have easy access to all in­form­a­tion available. It is for this reason that extra care is taken to ensure all Scrum artefacts are clear and easy to un­der­stand. The product owner is re­spons­ible for the product backlog. The backlog is a sorted list of all elements that are crucial for the product. This includes the func­tion­al­ity of the product and bug fixes or im­prove­ments.

The work for the product backlog is ongoing. The list is managed in a dynamic way – new insights are in­cor­por­ated at all times, entries are strongly dis­tin­guished, new tasks are added, and the sorting is adapted. At the beginning, the product owner is usually assisted by the Scrum master. The master knows from ex­per­i­ence how to formulate the document to be as trans­par­ent and effective as is required. Entries should generally be oriented towards the customer. In addition to a de­scrip­tion of the required feature, the document also contains a note on the workload and an entry on the priority level.

The sprint backlog is generated from the product backlog. This contains all entries of the product catalogue selected while planning for the upcoming sprint. It shows all steps leading up to the current sprint. During the daily scrum, the progress will be judged by the sprint backlog. This list can also be updated during the sprint to meet the team’s needs and chal­lenges. Now it is also the re­spons­ib­il­ity of the de­velopers to make changes in the sprint backlog. Neither the product owner nor the Scrum master may change the list.

At the end of a sprint, the de­velopers present the increment, i.e. the result of the de­vel­op­ment phase. The increment should include all sprint backlog entries and all in­cre­ments of previous sprints. It should always be directly de­liv­er­able at any required moment. It should be ready for use, even if there are no actual plans to deliver the product increment. In the sprint review, the team in­tro­duces the increment and the product owner and stake­hold­ers can review the results.

Scrum offers a number of ad­vant­ages compared to other agile methods, as well as tra­di­tion­al project man­age­ment methods. These are mostly due to the step-by-step approach and the small number of rules that may limit the team:

• Com­mu­nic­a­tion: Good project man­age­ment can only function when all team par­ti­cipants are on the same level. Scrum places a lot of emphasis on com­mu­nic­a­tion in the team. There is therefore a re­l­at­ively large number of events. The daily meeting at the beginning of the day makes sure that no developer works past the others. Any problems with the team are addressed in the final ret­ro­spect­ive.
  
  
• Flex­ib­il­ity: Scrum is used for re­l­at­ively short sprints. Since there is a maximum of one month between the two planning meetings, the project can also be changed at short notice and adapted to any new re­quire­ments.
  
  
• Trans­par­ency: Both the constant com­mu­nic­a­tion of all team members and the Scrum artefact system ensure high trans­par­ency. Backlogs are for­mu­lated in such a way that everyone can easily find their way around them and can find any necessary in­form­a­tion.
  
  
• Quality control: The iterative principle of Scrum ensures con­tinu­ous control of the product. Bug fixes are just as much a part of the product backlog as the further de­vel­op­ments. In the sprint review, the de­vel­op­ment team also presents a finished increment. The product owner and stake­hold­ers have the op­por­tun­ity to convince them­selves of the quality. This makes it possible to respond much faster to de­vel­op­ment­al errors than to find a faulty function at the very end of a project.
  
  
• Cre­ativ­ity: Scrum is based on the self-or­gan­isa­tion of the team. Instead of dictating the working processes from top down, the de­velopers start working with their own ideas first. Since the framework of Scrum is com­par­at­ively open and has few rules, in­di­vidu­al team members are more en­cour­aged to bring ideas to the table.
  
  
• Ef­fect­ive­ness: Compared to classic project man­age­ment, Scrum requires much less doc­u­ment­a­tion. The focus should be on a func­tion­ing product and not on complete doc­u­ment­a­tion that costs both time and resources. Instead, the team can con­cen­trate fully on the de­vel­op­ment work during the sprint and carry it out as it sees fit.

Despite the obvious ad­vant­ages, Scrum is not suited to all busi­nesses. Due to the dis­ad­vant­ages explained below, it is not the ideal solution for many companies:

• Lack of overview: What can be a big advantage for one team, can be a major dis­ad­vant­age for another. The in­cre­ment­al planning can sometimes result in a team losing sight of the bigger picture in a complex project.
  
  
• Complex com­mu­nic­a­tion: Scrum events are all pre-arranged, and for many teams and projects, such a high level of com­mu­nic­a­tion is un­ne­ces­sary. In such cases, the daily Scrum may hinder pro­ductiv­ity rather than encourage it. Too much time is spent on or­gan­isa­tion and com­mu­nic­a­tion instead of working on the actual product.
  
  
• Un­cer­tainty regarding planning and re­spons­ib­il­ity: Scrum ensures that teams organise them­selves. This can be be­ne­fi­cial, but in some areas and in­dus­tries, such a flat hierarchy can also lead to confusion in planning and ambiguity regarding who is re­spons­ible for what.
  
  
• Not in­teg­rable: Scrum can only be in­teg­rated into some companies with sig­ni­fic­ant ad­just­ments to the structure of the company. In such cases, the question arises, whether one loses more ef­fect­ive­ness than one gains through Scrum.

Whether or not Scrum is suitable for your business, ul­ti­mately, you’ll need to decide for yourself. Consider whether the flat hier­arch­ies and regular com­mu­nic­a­tion syn­onym­ous with Scrum will increase pro­ductiv­ity and improve job and product quality in your op­er­a­tions.