What is a Scrumbut?

The intention of Scrumbuts

The intention of a Scrumbut is usually the optimisation or adaptation of the work according to Scrum in and for a concrete organisation. The renunciation of parts of Scrum can result in

• accountabilities and tasks of the Product Owner, the Scrum Master and the developers,
• the organisation of events (sprints, sprint planning, daily scrum, sprint review or retrospective),
• the use of artefacts (product backlog, sprint backlog and increments) or
• the use of commitments (Product Goal, Sprint Goal or Definition of Done).

The range for possible scrumbuts is very wide, extending from the interpretation of roles (“For us, the product owner is not that important.”) to the duration and frequency of individual events (“We perform a sprint planning once at the beginning of the project.”) to the artefacts (“Instead of product or sprint backlogs, we use our internal project documents.”).

In practice, there are also scrumbuts that do not correspond to the positive intention. The implementation of workshops to determine requirements is not defined in Scrum, even if such workshops can be useful. Not to do something, although it would be positive for the development of a solution, is not in the sense of Scrum, so that also here one can speak of a Scrumbut.

Scrumbut Syntax

Scrumbut can usually be recognised by a typical syntax:

• Scrumbut,
• reason,
• workaround.

Example:

In some publications alternative examples are used: “We sprint 6 to 12 weeks to avoid problems”. This is also a scrumbut, a deviation of the recommended sprint length from one to four weeks. The sentence could also be “We use Scrum, but we often have trouble with effort estimates, so we use sprints with a duration of 12 weeks”.

Reasons for Scrumbuts

There are various reasons for using Scrumbuts. Some teams use them to solve problems at short notice. They are often under time pressure and a modification seems to help solve a problem. The 2017 State of Scrum Report by the Scrum Alliance states that 86% of teams perform a Daily Scrum, 11% perform it several times a week but not daily, 2% perform it on demand and 1% do not perform it at all. This example shows that 14% work with Scrumbuts. With Scrumbuts, one or more practices are omitted or adapted depending on the individual situation. Scrumand, on the other hand, adds one or more practices to Scrum, i.e. ‘We use Scrum and …’.

Scrumands can be found relatively frequently in organisations. For example, the Scrum Guide says nothing about user stories, epics or taskboards, although these elements are widely used in the agile world. The use of these aspects does cause some effort, but they are generally considered to be very useful and are consistently viewed positively. Scrumbuts, on the other hand, can be dangerous because established practices are consciously or unconsciously omitted. It is therefore advisable to develop Scrumbuts carefully, gain concrete experience – as with the use of Scrum – and make further adjustments if necessary.

One frequently cited reason for adapting the approach is the environment of an organisation: in some industries, special obligations to provide evidence apply, in others working with requirements specifications is established, in others extensive contracts are negotiated. Nevertheless, Scrum – with a few adaptations as Scrumbut or Scrumand – can be used sensibly. There are also approaches to understanding company transitions to Scrum as Scrumbut, because the roles, activities and artefacts are not yet established at the beginning of the introduction, so that they cannot (yet) be used as described in the Scrum Guide.

Types and examples of Scrumbuts

There are different types of Scrumbuts. They exist for

• Roles,
• events and
• artefacts, and
• arise from unawareness.

Scrumbuts for roles

There are Scrumbuts that refer to roles or accountabilities. Here are some examples. We use Scrum, but …

• we are very effective, work in a self-organised way and do not need a Scrum Master.
• our stakeholders are too busy to participate in the Sprint Reviews, so we don’t invite them at all.
• we develop different products in parallel, so we have a separate department with testers.
• we are a small company, so our development consists of one employee.
• always looking after the developers is boring in the long run, so everyone takes on the role of Scrum Master at some point.
• self-management doesn’t work properly for us, so the Product Owner assigns user stories to the developers.
• the Product Owner doesn’t have much time, so he formulates the requirements in such detail that he doesn’t have to take part in Sprint Planning.
• we have so many development tasks, so our Scrum Master also develops software as part of the team.
• our Scrum Master has already worked in many companies, so he can give clear instructions based on his experience.
• our project managers are very good, so they support our Scrum Masters in managing the respective teams.

Scrumbuts at events

There are Scrumbuts that relate to the events, the duration, the frequency and the way they are organised. We use Scrum, but …

• retrospectives are not effective, so we only do one at the end of the release.
• we work with a waterfall in the sprint, so we only test all realised user stories at the end of the sprint to be on the safe side.
• Sprint Planning takes too long for us, so the Product Owner makes the announcements about who should develop what and how.
• our developers are constantly communicating with each other, so we only do the Daily Scrum once a week.
• we usually don’t achieve our sprint goal in the short sprints, so we don’t define sprint lengths and work until we have realised all user stories.
• we have a hard time estimating effort and technical contexts, so our sprints last 12 weeks to be on the safe side.
• for us, two sessions in Sprint Planning make little sense, so we do joint planning in half the time.
• we don’t believe in timeboxing for the many meetings, so we simply leave it out with the exception of the sprints.
• if we only ever plan for the next release or the next sprint, we lose the overview, so we always plan for three releases in advance.

Scrumbuts for artefacts

There are Scrumbuts that relate to artefacts. Here are some examples. We use Scrum, but …

• our client would like to see a customer specification from us, so we create one for them for each sprint.
• we want clear responsibility between development and testing, so we divide the user stories into development or test stories accordingly.
• the effort estimate is too imprecise for us, so we also estimate the effort for the development of backend, frontend, integration and testing for each user story.
• we have had good experience with the horizontal refinement of user stories, so we do without vertical refinement even if we cannot deliver an increment at the end of the sprint.
• as we only make our releases available to our customers, we only produce the delivery result on demand or once at the release date.
• as all employees are active in different projects and the time pressure is high, we sometimes do not adhere to the definition of done.
• we don’t need a separate sprint backlog, so we simply use the information in the product backlog.
• because our product backlog is so large, we also manage backlogs for epics, features and customer requests.
• our top priority is to stick to our initial release plan, so we often work overtime to stick to it.

Scrumbuts due to not knowing

Scrumbuts can certainly be justified – as long as they are consciously understood as a deviation from Scrum, introduced, reviewed and, if necessary, adapted. However, Scrumbuts that are the result of ignorance rarely lead to positive effects. They are often based on unproven assumptions, prejudices or opinions of individual employees. Here you will find possible examples of Scrumbuts due to not knowing:

• Management has heard that ‘agile’ is so easy and good, so now we do Scrum for the most part.
• Scrum only consists of a few responsibilities, activities and artefacts, so no training is necessary.
• We have 15 developers and we don’t want to split them into two unevenly sized teams, so we just work with one team as usual.
• We do 100% Scrum, so we simply leave out all aspects that are not described in the Scrum Guide.
• Why should we train or even certify employees?
• Scrum stands for openness and feedback, so we also document this publicly.
• We simply take the best elements from Scrum and if it doesn’t work, then we don’t do it again.
• Trust is all well and good, but we achieve our goals faster with clear announcements.
• Why should we talk to each other about our experiences – every employee has the same ones.

The customisation of Scrum and the conscious use of Scrumbuts

Scrum follows the values set out in the Scrum Guide and the Agile Manifesto. The Agile Manifesto states, among other things, that functioning software is more important than comprehensive documentation. This does not mean that documentation is unimportant, it is just less important in relation to functioning software. There are now organisations that create a specification for each sprint based on items from the sprint backlog and tasks defined by the team. Scrum does not provide for such a specification document, but such adaptations can still be useful for organisations. Ken Schwaber, one of the authors of the Agile Manifesto, recognised early on that it is legitimate to deviate from the defined principles.

Thinking a little further ahead, it may even be necessary for organisations to deviate from the defined approaches. Does a retrospective have to take place after every sprint or is it also sufficient at the end of a release? Can a timebox last 20 minutes instead of just 15? It is crucial for organisations to consciously answer such questions based on concrete challenges; the agile manifesto and the Scrum Guide only provide recommendations here.

Some discussions give the impression that adapting Scrum is a bad idea – this is not the case. In fact, adapting a general framework to individual situations is absolutely necessary. Even though the 17 authors of the agile manifesto and the two authors of the Scrum Guide have a lot of experience in developing products and working in teams, they do not know all the individual situations and challenges of an organisation.

When organisations are looking at adapting Scrum, they should have gained a deeper understanding of Scrum. Such an understanding develops over time and through adherence to and application of the defined accountabilities and rules. Only then can an adaptation achieve the desired effect. An adjustment that merely disguises a problem and does not solve it does not make sense. If, for example, a Product Owner is not available on a regular basis and therefore cannot attend the necessary events, the focus should not be on improving the documentation of requirements, but on relieving the Product Owner. It is therefore advisable – as with Scrum itself – to constantly scrutinise and adapt Scrumbuts, as this allows the adaptation to have the best possible effect.

Notes:

Here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.