Scrum, but…
The term “Scrumbut” is now often used to refer to incorrect understanding or intended modification of Scrum rules. Scrumbuts are reasons why teams can’t take full advantage of Scrum to realize the full benefits of agile product development, along with the solutions that teams implemented instead of using Scrum practices.
A typical Scrumbut formula looks like this:
<We use Scrum, but> <we have these unique circumstances> <so we have had to modify Scrum so it works here>
Or, in a shorter format:
<Scrum, but><reason><workaround>
Often, circumstances create blockers for the team on their way of adopting Scrum practices. Quite often these blockers cannot be removed for a reason, and that is where Scrumbuts are created. These blockers can be both internal and external. Internal blocker would describe something that comes from lack of understanding of how Scrum should work, or lack of will, or power to change internal processes and/or approaches and remove blockers. External blockers are organization-wide practices, structure, beliefs, and processes, that the team is dependent on, especially in the early stages of transition or resulting from lack of understanding of Agile and Scrum practices by management of an organization.
A workaround is a way of ignoring or altering certain Scrum practices as a result of a blocker. Alternatively, it can be described as a way of focusing on symptoms rather than on reasons that are causing an “organizational disease.”
Common examples of Scrumbuts look like this:
– We have Scrum, but we not always can have all the work done within a sprint, so we extend sprint’s length.
– We have Scrum, but we have too many stakeholders, so we do not conduct Sprint Review meetings
– We have Scrum, but we are understaffed, so we have developers participating in multiple teams
We should not confuse Scrumbuts to organic evolutionary steps that a team would undertake on the way of becoming a mature scrum team, therefore the term shouldn’t be overused.
However, Scrumbuts in an established team most likely originate from the lack of understanding of agile development practices or Scrum framework by either the team itself or higher management. It is easy to check if this is the case by simply asking a team to provide a reason of adopting this modification to Scrum practices. It is not that often when this reason turns out to be a valid one.
For example, if you don’t have code reviews, pair programming, or team members are specializing in certain areas of the product, perhaps you’re simply in the very beginning of your Scrum journey. On the other hand, if the same applies to mature teams, the real reason behind it can be anything from inability to sell the concept to the management, to inability to implement the framework properly and benefit from it.
Dealing with Scrumbuts is one of the most important tasks that a Scrum Master should facilitate. However, do not forget that continuous improvement is a responsibility of the entire team and cannot be tasked to the Scrum Master only.
Here is a list of common blockers and workarounds that many teams are implementing around the world. All projects are different, and for some these Scrumbuts can be justified. However, this list can be used as an agile health check and a way to discover such workarounds within your teams.
If anything from this list corresponds to your current practices, ask yourself why did you adopt such a practice and is there a way to improve related processes?
COMMON “WORKAROUNDS” IN SCRUM:
PROCESS:
1. Scrum Team doesn’t own or manage its development process
2. The team doesn’t focus on continuous improvement of their processes
3. Team fails to follow an established action plan to improve performance
4. There is no available list of team problems, as well as improvement plan
5. There is no time or budget allocated for solving problems
6. Sprints are getting extended or shortened
7. Sprint length often changes from one sprint to another
8. Work within sprint goes in phases (water-scrum-fall)
9. Team works overtime to achieve sprint goal or complete all the stories on a regular basis
10. Work doesn’t have a constant rhythm, there are pauses between sprints
11. Absence of common understanding of a workflow within the team
12. Extra work is frequently added to the sprint
13. There is no designated support team or there is no allocated time for application support for the Scrum Team
14. Selected tools determine process (Jira, VSTS, etc.)
15. Some of the Scrum ceremonies are not happening on regular basis
PRODUCT:
16. Product vision, release vision, and sprint goals are not clear to the Scrum Team
17. Sprint Goals are not corrected based on shareholders’ or users’ feedback
18. Backlog contains descriptions of solutions
19. Value of PBIs cannot be clearly understood from the backlog
TECHNOLOGY:
20. Team hasn’t established Definition of Done, or it is not clear for team members
21. Absence, or rare use of agile development practices, such as CI, Code Review, Refactoring, TDD, etc.
22. Lack of testing by developers; High volume of bugs discovered in QA / UAT
23. QA activities are happening in separate sprints from development
24. Lack of automated tests
PRODUCT OWNER:
25. PO is not working with / hard to reach by the team during the sprint
25.1 Po is a client’s representative, working on client’s side
26. PO doesn’t have time to work with all the assigned teams
27. PO is not making product-related decisions (What needs to be developed and in what order)
28. Teams have multiple POs
29. POs prioritization isn’t based on business value
30. PO tries to get all the features done ignoring Pareto Principle (80/20 rule, 80% of profits are coming from 20% of feaures)
31. PO is a boss of the Scrum Team
32. PO is not invited to Sprint Retrospective
33. PO doesn’t know key stakeholders and clients
34. PO doesn’t provide feedback to the team
35. PO dictates how solutions should be built
SCRUM-MASTER:
36. Scrum Master’s work is performed by one of the Developers or a PO
37. Scrum Master changes every sprint
38. Scrum Master is not located next to the team
39. Scrum Master lacks soft skills to effectively work with people
40. Scrum Master lacks courage to disagree with team’s decisions that contradict Agile / Scrum principles and values
41. Scrum Master dictates how solutions should be built
42. Scrum Master performs POs work
43. There is 1 Scrum Master for more than 3 — 4 teams
TEAM:
44. No common goal (for product, release, sprint)
45. There is no sense of shared responsibility for completion of sprint goals
46. Team members have their areas of responsibility without understanding of work outside of their area
47. Development team is divided into sub-teams, taking care of separate components or focusing on separate horizontal layers
48. Team members change throughout the sprint
49. Team members are working on other projects in parallel
50. Team members are appreciated / penalized on individual basis
51. Team doesn’t have enough skillset to complete all the work on their own
DAILY WORKFLOW:
52. Daily Standups are not happening on regular basis or start later than planned
53. Daily Standups are conducted at the team members’ desks
54. Development Team reports their progress to SM or PO on Daily Standups
55. There are discussions on Technical or Business solutions happening during daily Standups
56. Daily Standups are taking longer than 15 minutes
57. Daily Standups are not in the same room
58. If working as a remote team, daily standups are happening separately based on location of team members
59. The team is getting interrupted by others during team meetings
60. Team members are using gadgets during the team meetings
61. Team works on PBIs without taking items’ priority into consideration
PLANNING:
62. Team doesn’t work with the Product Backlog prior to the planning meeting (Grooming, Refinement, etc.)
63. Team commits to delivering Sprint Backlog rather than to the Sprint Goal
64. Team agrees on who would be working on which tasks during the sprint
65. The work that was not completed in the sprint is automatically transferred to the next sprint
66. Too many changes are happening within a sprint
67. Team overcommits on a regular basis so there is always some incomplete work at the end of the sprint
68. Not all the team members actively participating in planning, estimating, designing a story
69. Not every team member knows what needs to be done under every user story taken to the sprint
70. User stories in sprint backlog are often massive. Team fails to split these user stories.
71. User Stories are broken down by horizontal layer, or by screen, without taking business value behind the story into account
END OF SPRINT:
72. No tracking of successful and unsuccessful sprints
73. Sprint is considered to be unsuccessful if Sprint Backlog is not fully cleared, without taking Sprint Goal into consideration
74. Stories are considered done even if there are unresolved bugs in them
75. Demo is happening without structure
76. Development team is not participating in the Sprint Review
77. Stakeholders’ feedback is not collected during the Sprint review
RETROSPECTIVE:
78. Team is looking for certain team members to blame for failing the sprint
79. There is no action plan generated at the end of the Retrospective meeting
80. Retrospectives are always following the same scenario
81. Problems are identified, action plan is created, but team never follows it
82. There are no metrics to measure performance
MANAGEMENT:
83. There is a manager of the project responsible for successful implementation of the project
84. Managements doesn’t understand the nature of team estimates and requires to “stick to the promise” without taking into consideration if team achieved the Sprint Goal or not
85. There are development managers, scrum managers, release managers, and other sorts of managers, responsible for part of the work
86. Managers are using team artifacts or velocity to measure team’s performance
87. Managers are using Scrum Master as a leverage to increase team’s speed
88. Scrum is imposed by management, without understanding of agile values and principles
WORKPLACE:
89. No convenient ways of communication with remote team members
90. No convenient rooms for team meetings
91. Cubicle-type office, teams are separated or not sitting together
92. Inconvenient workplace to work in pairs
I am surprised if you made it to here! And as you made it this far, here’s another important piece of information about ScrumButs:
– There is nothing wrong about having a positive ScrumBut
This goes with a condition. And the condition is that the existing ScrumBut must be the most logical solution suiting a particular team or a project. Solution that maximizes efficiency of the team.
This means that if the “unique circumstances” we’re referring to can be adjusted, we should follow Scrum practices, rather than alter them to fit the environment. If circumstances can only be addressed with a Scrumbut, a team can agree to follow this practice. After modification to the process is made, a change in performance should be also measured. If ScrumBut brings productivity down — it is a negative ScrumBut and must be avoided!
At the same time, if a mature team follows the Scrum framework, but feels like certain Scrum practice is not efficient and can be modified to improve efficiency, they may try incorporating a Scrumbut. Changes caused by every workaround should be measured.
Scrum is a well-established framework, but it should not be followed blindly. What works for one team may not be applicable to the other. That’s why my advice for all the Scrum teams is to implement Scrum to its best, and then adjust it with ScrumButs as needed. Any time you have to assess the chosen methodology remember: “Individuals and interactions over processes and tools”.