85 misconceptions and obstacles to introducing agile development

The term "scram-bat" (from "scrum, but ..") first began to use Ken Schweiber to describe an incorrect interpretation or intentional modification of scram rules to escape the painful truth about the process, which he helps to open.

A typical scram-batch formulation is:
We have a scrum, but <Reason>, <Bypass Path>
')
Where Reason is a description of discomfort, an unpleasant discovery with which a team cannot cope for any reason. A workaround is a way to close your eyes to a problem, or to eliminate the "symptoms" without understanding the causes of "organizational disease."

Typical examples of scrum-bats, respectively, look like this:

• We have scrum, but we do not always have time to finish all the work taken, so we change the length of the iteration.
• We have scrum, but all the problems that we could fix we have already eliminated, so we do not hold retrospectives.

We try not to abuse the term "scrabat", 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 scrum, but you do not do TDD, you do not have pair programming and poorly expressed collective ownership of the code - perhaps you are just at the beginning of the path. The reasons may be different - from the inability to “sell” the value of engineering practices to management to the inability to “prepare” them. Both can be learned to do, but it takes time, right?

However, every time I hear “we have scars, but” in mature teams, I try to hear more about the reasons for this modification. And you know what? Good reasons are actually very few. Rather, it is a lack of understanding of the values ​​of agile development, a lack of courage and strength to follow them, which together form the process "scrambled".

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 karsass scrum. Depending on the project context, some items may have more or less influence, and have excuses for circumstances. However, we believe that every element of this list provokes a distortion of Agile values ​​and principles.

If you are already working on the scrum framework, or modifying it, you may find this list useful for self-diagnostics. Try asking yourself the questions: “Hmm, why do we really have it?” And “What else can we do to change the situation?” For each item that relates to your process.

It became interesting for me to rank this list and get a top list of obstacles that agile development teams have to face in a Russian-speaking space. I would be grateful for your help in this (a questionnaire with the same points on the link ) and I will definitely share the results. So,

WITH WHAT DIFFICULTIES AND OBSTACLES DOES IT HAPPEN TO 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 the accepted changes.
4. There is no list of problems and systematic work on their elimination.
5. No investment is allocated (time, money) to work on problems
6. The length of the sprint increases in 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 meets the timeline to achieve the goal of a sprint or to perform a full backlog
9. Irregular developmental rhythm with pauses between sprints.
10. There are no agreements on the working process (Working agreements)
11. With a fixed volume of tasks for the sprint, new tasks are regularly thrown.
12. No specific people or team time has been allocated to support a functioning product.
13. The limitations of the acquired tool determine the process (Jira, TFS, etc.)

PRODUCT

1. No tools are used to work on vision and business value (product techniques such as BMC, Personas, Effect Maping, Story Mapping, etc.)
2. Vision of the product, goals of releases and sprints are not conveyed to all team members
3. The objectives of the iterations are not adjusted based on feedback from the market (after going live)
4. The product backlog contains specific ways to implement
5. Product backlog does not display the value of items in it.
6. The product backlog contains large stories (in half sprint), the team does not know how to break them into smaller ones

TECHNOLOGY

1. Definition of Done criteria are not defined or communicated to team members.
2. Lack or weak use of engineering practices (CI, Code Review, Refactoring, TDD, etc.)
3. Team members commit code without testing the build
4. Testing work is not included in one development sprint.
5. Testing is not automated

PRODUCT OWNER

1. Product Owner Unavailable during the Sprint
2. The Product Owner does not have enough time to work with all the teams in sufficient volume.
3. The Product Owner has no power to make decisions.
4. There are several Product Owners for one team.
5. Product Owner Priorities are not based on learning strategy and business value.
6. The Product Owner seeks to implement all features without using the Pareto principle to work with backlog.
7. Product Owner - Master Scrum boss
8. Product Owner is 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. Product Owner does not know its key users and customers.
11. The product owner does not give feedback to the team.

SCRAM MASTER

1. There is no dedicated Master Scrum or it changes every sprint
2. Scrum Master is in a different location than the team.
3. Skram-Master lacks knowledge of agile development (principles, values, practices)
4. Skram-Master has not enough social skills (soft skills) to work with people.
5. Scrum-Master has not enough courage to resist the decisions of the team, contrary to the values ​​of Agile
6. Scrum Master is a technical leader and dictates its decisions to the team.
7. The Scrum Master “in combination” plays the role of the Product Owner.
8. One Scrum Master works on more than 3-4 teams.

TEAM

1. 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 poor understanding of the work of their colleagues.
4. The development team is divided into specialized component / layer sub-commands.
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 meetings are unsystematic and / or late.
2. The daily rally is held sitting at the workplace.
3. The development team on the Daily reports to the Master Master or Product Owner.
4. Technical and business decisions are discussed during the Daily, delaying this rally for more than 15 minutes.
5. In a distributed team are individual Daly locations
6. The team is distracted during the meeting (Planning, Daily, Retro, Demo)
7. Team members are distracted by gadgets at meetings.
8. The team works on backlog in a random order, not taking into account the priorities of the Product Owner.

PLANNING

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

DEMONSTRATION

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

RETROSPECTIVE

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

MANAGEMENT

1. There is a project manager who is 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 they are asked to “fulfill the promise”
3. There are development managers, release managers, scrum managers and other types of managers responsible for a dedicated part of the work.
4. Managers use command artifacts as an estimate and expect to get “beautiful” diagrams (burndown) and velocity (velocity).
5. Managers have pressure on the Scrum Master and “squeeze” the speed of the team through it
6. Enforcement of Scrum by management that does not follow Agile principles and values

WORKSPACE

1. 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 the tables
4. Inconvenient room for pair work

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

If you want to challenge some of the items in 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 the teams with which we in SCRUMguides , or our colleagues had to work.

In addition, disputes on 85 points are just too tough for my free time reserves :) But I will be happy 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 in coaching format.