What is a Scrumbut?
Scrumbut Definition
The abandonment of individual elements in Scrum (events, accountabilities or artefacts), and thus the deviation from the standard as stated in the Scrum Guide, is called Scrumbut. The expression goes back to “We use Scrum, but …”.
Opinions differ as to whether a Scrumbut is bad in any case or whether it should be considered sensible. On the one hand, a Scrumbut is not desirable as it indicates that the team is not fully committed to the principles of Scrum and may not be getting the full benefits of the methodology. On the other hand it’s important to note that Scrum is a framework that can be adapted to suit the specific needs of a team or project. In some cases, a team may make modifications to Scrum that work well for them and still achieve success. So, whether a Scrumbut is good or bad depends on the specific situation.
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 several reasons for using scrumbuts. Some teams use scrumbuts to solve short-term problems. Often they are under time pressure and a modification seems to help solve a problem. In order to save time, individual Daily Scrums, for example, could be omitted as there is concern about missing a sprint goal. An acute problem could be solved in this way, but in the long run this should not lead to a reduction of Daily Scrums with such a justification. Causal problems – e.g. the incorrect estimation of expenses – often reappear at later points in time.
A frequently cited reason for adapting the approach is the environment of an organisation: in some sectors special obligations to provide documentary apply, in others work with customer specifications and requirement specifications is established, in others extensive contracts are negotiated. Nevertheless Scrum – with some adaptations as Scrumbut or Scrumand – can be used meaningfully. There are also approaches to understand transitions from companies to Scrum as Scrumbut, because the roles, activities and artefacts are not yet established at the beginning of the implementation, so that they are not (or cannot be) used as described in the Scrum Guide.
The Agile Manifesto
Scrum follows the values that are recorded in the Scrum Guide and the Agile Manifesto. Among other things, this Agile Manifesto says that functioning software is more important than comprehensive documentation. This does not mean that documentation is unimportant, it is only less important compared to functioning software. Now there are organisations that create a specification for each sprint based on sprint backlog items and tasks defined by the team. Scrum does not provide such a specification document, but such adaptions can be useful for organisations. Ken Schwaber, one of the authors of the Agile Manifesto, recognised early on that the deviation from the defined principles was legitimate.
A little further down the line, 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 enough at the end of a release? Can a timebox also last 20 minutes instead of just 15? It is crucial for organisations to consciously answer such questions by means of concrete challenges; the Agile Manifesto as well as the Scrum Guide merely provide recommendations.
Is a Scrumbut good or bad?
Some discussions give the impression that adapting Scrum is a bad idea – that’s not the case. The adaptation of a general methodology to individual situations is even 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 individual situations and challenges of a company.
When adapting Scrum, it is important to consciously deal with a concrete challenge. This presupposes that the adaptation is not only a short-term elimination of a problem as a quick fix. With Scrumbut problems should be solved and not concealed. If, for example, a Product Owner has to manage several products and therefore cannot attend meetings, it would not be a good solution not to invite him to the meetings anymore; it would make more sense to distribute his workload among other employees so that he can actually fulfil his responsibility.
Scrumbut and Scrumand
The 2017 State of Scrum Report of the Scrum Alliance noted that 86% of teams perform a Daily Scrum, 11% perform it several times a week but not daily, 2% on demand and 1% not at all. This example shows that 14% work with Scrumbut. With Scrumbuts, one or more practices are omitted or adapted depending on the individual situation. Scrumand on the other hand supplements Scrum with one or the other practice, i.e. “We use Scrum and …”.
Scrumands can be found relatively often in organisations. The Scrum Guide does not say anything about user stories, epics or taskboards, for example, although these elements are widespread in the agile world. While the use of these elements is a bit of an effort, they are generally considered to be very useful and consistently positive. Scrumbuts, on the other hand, can be dangerous because established practices are deliberately or unconsciously omitted. It is therefore advisable to develop scrumbuts carefully, to gain concrete experience – as with the use of scrum – and to make further adjustments if necessary.
Download the Scrum Whitepaper for free now.
Everything important about the framework at a glance.
- Events
- Accountabilities
- Artefacts
- Values
- Benefits
- Tips
Knowledge on 13 pages to take away.
Scrumbuts with Roles
There are scrumbuts that refer to the roles or the interpretation of the roles. Here are some examples. We use Scrum, but …
- we are very effective, work self-organised and do not need a Scrum Master.
- our stakeholders are too busy to participate in the sprint reviews, so we don’t invite them anymore.
- 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 taking care of the developers is boring in the long run, so everyone takes on the role of Scrum Master once.
- we don’t manage ourselves properly, 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 participate in the 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 with his experience.
- our project managers are very good, so they support our Scrum Masters in managing the respective teams.
Scrumbuts with Events
There are scrumbuts that relate to the activities, the duration, the frequency and the way they are carried out. We use Scrum, but …
- retrospectives are not effective, so we make only one at the end of the release.
- we work with a waterfall in the sprint, so we test all realised user stories at the end of the sprint to be on the safe side.
- for us the sprint planning takes too long, so the product owner announces who should develop what and how.
- we communicate permanently with each other, so we only do the Daily Scrum once a week.
- most of the time we didn’t reach our sprint goal in the short time of the sprints, so now we don’t define the sprint lengths and work until we have realised all user stories.
- we have a hard time with the effort estimation and technical connections, so our sprints take 12 weeks just to be on the safe side.
- two sessions in sprint planning don’t make much sense for us, so we do joint planning in half the time.
- we don’t believe in timeboxing at the many meetings, so with the exception of the sprints we just leave it out.
- if we only plan for the next release or sprint we lose the overview, so we always plan for three releases in advance.
Scrumbuts with Artefacts
There are scrumbuts that refer to the artefacts. Here are some examples. We use Scrum, but …
- our client would like to see a requirement specification from us, so we create one for every sprint.
- we want a clear responsibility between development and testing, so we divide the user stories into development and test stories accordingly.
- the effort estimate is too inaccurate for us, so we additionally estimate the effort per user story for the development of backend, frontend, integration and testing.
- we have had good experience with the horizontal refinement of user stories, so we do without vertical refinement even if we can’t deliver an increment at the end of the sprint.
- since we only make our releases available to our customers, we only produce the delivery result on call or once at the release date.
- since all employees are active in different projects and the time pressure is high, we sometimes do not comply with 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 keep to our initial release plan, so we often work overtime to keep to it.
Scrumbuts due to Ignorance
Scrumbuts can have an authorisation – as long as they are consciously understood, introduced, checked and if necessary adapted as a deviation from Scrum. Scrumbuts that are based on ignorance, however, rarely have positive effects. They are often based on unproven assumptions, prejudices or opinions of individual employees. Here you will find possible examples of scrumbuts caused by ignorance:
- Management has heard that “agile” is so simple and good, so now we’re mostly doing Scrum.
- Scrum consists of only a few roles, activities and artefacts, so no training is necessary.
- We have 15 developers, but we don’t want to divide them into two different teams, so we just work with one team as usual.
- We make 100% Scrum, so all aspects that are not described in the Scrum Guide are simply omitted.
- Why should we train or even certify employees?
- Scrum stands for openness and feedback, so we document this publicly.
- Now we simply take the best elements out of Scrum and if it doesn’t work out, then we let it go again.
- Trust is all well and good, but with clear announcements we reach our goals faster.
- Why should we talk to each other about our experiences – every employee does the same.
The Conscious Handling of Scrumbuts
Developing software, products and services with Scrum is not always as easy as it might sound at first glance. It can therefore be useful for companies to adapt the procedure to the concrete challenges and opportunities. Nobody gets an star in the grade book if a development is done 100% according to Scrum.
If organisations are concerned with adapting Scrum, they should have a deeper understanding of Scrum. Such an understanding evolves over time and through the observance and application of the defined accountabilities, rules and rituals. Only then can an adaptation – a scrumbut – achieve its desired effect. An adaptation that only obscures a problem and does not solve it does not make sense. For example, if a product owner is not regularly available and therefore cannot attend the necessary meetings, the focus should not be on improving the documentation of requirements, but on relieving the product owner. The lack of communication is the weak point, and a scrumbut is probably of little help here. It is therefore advisable – similar to Scrum itself – to question and adapt Scrumbuts again and again, because in this way the adaptation can unfold the best possible effect.
Notes:
Here you will find additional information from our Smartpedia section:
How does Sprint Planning work?
What are good tips for the Sprint Review?
What methods exist for Retrospectives?