85 Misconceptions and Obstacles to Agile Implementation / SCRUMguides Blog

The term “scrum-bat” (from “scrum, but ..”) was first used by Ken Schueiber to describe an incorrect interpretation or deliberate modification of the scrum rules in order to escape from the painful truth about the process that it helps to open.

A typical scram-baht wording looks like this:
We have a scrum, but <reason>, <workaround>

where reason is a description of discomfort, an unpleasant opening which the team cannot cope for one reason or another. A workaround is a way to close your eyes to the problem, or eliminate the “symptoms” without understanding the causes of the “organizational illness”.

Typical scrum bats, respectively, look like this:

• We have a scrum, but we do not always have time to finish all the work we took, so we change the length of the iteration.
• We have a scrum, but we have already eliminated all the problems that we could eliminate, therefore we do not conduct retrospectives.

We try not to abuse the term “scrambat”, since some types of deviations are characteristic of the beginning of the introduction of agile and are part of the evolution of the process. For example, if you have a scrum, but you don’t do TDD, you don’t have pair programming and poorly expressed collective code ownership - perhaps you are just at the beginning of the way. The reasons can be different - from the inability to “sell” the value of engineering practices to management to the inability to “cook” them. Both can be learned to do, but it takes some time, right?

However, every time I hear “we have a scream, but” in mature teams, I try to hear something more about the reasons that such a modification causes. And you know what? Reasonable reasons are actually very few. Rather, it is a misunderstanding of the values ​​of agile development, a lack of courage and strength to follow, which together form a “scrambled” process.

Working with teams, we have compiled a list of 85 misconceptions and obstacles to the successful implementation of agile development. Many go beyond the rules of carcass scrum. Depending on the context of the project, some points may have a greater or lesser impact, and justification in circumstances. However, we believe that every element of this list provokes a distortion of Agile's values ​​and principles.

If you are already working on a scram framework, or modifying it, you might find this list useful for self-diagnosis. Try to ask yourself the questions: “Hmm, why is this really so?” And “What else can we do to change the situation?” For each item that relates to your process.

I became interested in ranking this list and getting a top list of obstacles that agile development teams have to deal with in the Russian-speaking space. I will be grateful for the help in this (a questionnaire with the same points here ) and I will definitely share the results. So,

WHAT MISCTIONS AND OBSTACLES HAVE TO FACE TEAMS IN AGILE / SCRUM PROJECTS

PROCESS

1. The team is not authorized or informed that it can change its development process
2. There is not enough courage in the team for a qualitative change in the process
3. There is not enough zeal in the team to follow accepted changes
4. There is no list of problems and systematic work on their elimination
5. No investments are allocated (time, money) to work on problems
6. Sprint length increases during its course or often changes
7. The work is divided into phases, each of which is performed in one sprint (“water-scrum-fall”)
8. The team regularly overtime to achieve the goal of the sprint or complete the backlog completely
9. Unstable rhythm of development with pauses between sprints
10. No working process agreements
11. With a fixed amount of sprint tasks, new tasks are regularly thrown
12. Individual people or team time were not allocated to support a functioning product
13. The limitations of the purchased tool determine the process (Jira, TFS, etc.)

PRODUCT

1. Vision and business value tools are not used (product techniques such as BMC, Personas, Effect Maping, Story Mapping, etc.)
2. Product vision, goal releases and sprints are not communicated to all team members
3. Iteration goals are not adjusted based on feedback from the market (after going live)
4. Product backlog contains specific implementation methods.
5. Product backlog does not display the value of elements in it.
6. The product backlog contains large stories (half a sprint in size), the team cannot break them into smaller ones.

TECHNOLOGY

1. Definition of Done criteria not defined or reported to team members
2. Lack or poor use of engineering practices (CI, Code Review, Refactoring, TDD, etc.)
3. Team members commit code without checking build health
4. Testing works are not included in one sprint with development
5. Testing is not automated

PRODUCT OWNER

1. Product Owner Unavailable During Sprint
2. The Product Owner does not have enough time to work with all teams in sufficient volume
3. Product Owner Does Not Have Decision Making Power
4. There are several Product Owners for one team.
5. Product Owner Priorities not built on training strategy and business value
6. The Product Owner seeks to implement all the features without using the Pareto principle for working with the backlog.
7. Product Owner - Scrum Master Boss
8. Product Owner Not Invited to Retrospective
9. The Product Owner does not have an available team to find the best ways to implement stories (Product Discovery Team: PO, UX, Architect)
10. The Product Owner does not know his key users and customers.
11. The product owner does not give feedback to the team

SCRUM MASTER

1. There is no dedicated Scrum Master or it changes every sprint
2. Scrum-Master is in a different location than the team
3. Scrum-Master does not have enough knowledge in the field of agile development (principles, values, practices)
4. Scrum-Master does not have enough social skills (soft skills) to work with people
5. Scrum Master doesn't have the guts to resist team decisions that contradict Agile values
6. Scrum-Master is a technical leader and dictates his decisions to the team
7. Scrum-Master "in combination" acts as the owner of the product
8. One Scrum Master works on more than 3-4 teams

COMMAND

1. There is no common goal (product, release, sprint)
2. There is no feeling that everyone is “sailing in the same boat”
3. Team members have a deep specialization and a poor understanding of the work of their colleagues
4. The development team is divided into specialized sub-teams for components / layers
5. The composition of the team changes during the sprint
6. Team members work on other projects in parallel
7. Team members are encouraged / punished individually

DAILY WORK

1. Daily rallies are unsystematic and / or delayed
2. Daily rally is held sitting at jobs
3. The Daily Development Team reports to the Scrum Master or Product Owner
4. Technical and business solutions are discussed during the Daily, delaying this meeting for more than 15 minutes
5. In a distributed team there are individual Daily locations
6. The team is distracted during the meeting (Planning, Daily, Retro, Demo)
7. Team members distracted by gadgets at meetings
8. The team works on the backlog in random order, not taking into account the priorities of the Product Owner

PLANNING

1. There is no preliminary work with the backlog for preparing for Planning (Grooming, Refinement, etc.)
2. The focus of team commenting during planning is on the sprint backlog, not its goal.
3. The team agrees who will work on what tasks during the sprint
4. Incomplete work of the past sprint automatically moves to the next

DEMONSTRATION

1. There is regular work in progress at the end of the sprint
2. There is no formal assessment of “successful” and “unsuccessful” sprints
3. Sprint is rated as “unsuccessful”, if the backlog is not fully completed, the achievement of the sprint goal is not taken into account
4. There are bugs in implemented stories, while they are considered complete
5. Demonstrations take place without preparation, no meeting structure
6. The development team presents the results of the sprint always to the Product Owner.

RETROSPECTIVE

1. Accusations and search of perpetrators take place during the meeting
2. At the end of the Retrospective there is no action plan with the dates and names of those responsible
3. Too many changes in one iteration
4. There are no metrics or ways to measure changes in the process.
5. Retrospectives always follow the same scenario, according to the same meeting patterns
6. Problems are identified, there is an action plan, but no action

MANAGEMENT

1. There is a project manager responsible for the success of its implementation to the top management of the company
2. Management does not understand the essence of team evaluations and the team is required to “keep the promise”
3. There are development managers, release managers, scrum managers and other types of managers responsible for the selected part of the work.
4. Managers use team artifacts as an estimate and expect to get “beautiful” charts (burndown) and velocity
5. Managers have pressure on the Scrum Masters and “squeeze” the speed of the team through it
6. Violent implementation of Scrum management that does not follow Agile principles and values

WORKSPACE

1. There are no convenient means of organizing communications in a distributed team
2. Inconvenient space for organizing team meetings
3. Office in open space format with partitions on tables
4. Inconvenient room for pair work

If you read to this place - take off my hat! Then perhaps you would like to add something else to this list? You can do this in the questionnaire , however, it will take another 5 minutes to fill out :) But thanks to your investment of time, we will be able to get interesting information for thought and action. No time to fill out?) - Just leave a comment on the article.

If you want to challenge some of the items on the list, I’m afraid I will have nothing to argue with: nobody knows your context better than you. These points appeared because they took place in teams that we had to work with at SCRUMguides or our colleagues.

In addition, disputes over 85 points are simply too tough for my reserves of free time :) But I will like to talk personally (skype, mail) and try to answer those who filled out the form and / or want to talk about the situation in the team at coaching format.