21

What was the single point of failure encountered when your company decided to replace the current processes with SCRUM?

Can you give me some examples of things that have gone really wrong when a company tried to introduce SCRUM? I'd like to hear your anecdotes, something you experienced yourself, the big fail that you saw coming but couldn't prevent.

I hear a lot of concern about missing documentation on decisions about the implementation details, and about story sizes and detail level of the stories.

Blake
  • 406
  • 2
  • 10
cringe
  • 608
  • 4
  • 12
  • 1
    I don't think questions with `You` are really a good fit for the stack exchange format. Since 'You' has a different meaning for each reader, this is effectively many different questions, not one, and asking readers to vote between the answers to different questions feels wrong. – bdsl Feb 25 '21 at 10:50

9 Answers9

15

The biggest problem is misunderstanding. Common failures are:

  • Only a team is doing Scrum but rest of the company (including sales, management, HR) still think in the old way. Examples:

    Continuous interaction with customer and customer's involvement is very important.

    HR has to understand that team performance is more important then performance of individuals. KPI must change to that.

    Feature definition is continuous process. Project definition will evolve during development by customer feedback. Because of that project deadline, required budget or result feature set can change (after approval by stakeholder).

    Change is part of the process.

    Estimation is continuous process you cannot say at the beginning of the project that you will be done with all features (many of them unknown at the beginning) within 5 months.

    Team is empowered to make decisions. Team makes commitment to amount of features delivered during next sprint. This cannot be demanded or commanded.

    Sprint is safe zone for the team. Once the team commits to some defined user stories the commitment cannot be modified outside of the team.

    Part of the old organization structure doesn't make sense when moving to Scrum. Scrum defines three roles: Scrum master, Product owner, team. There are other roles but these three are usually enough for delivering the application. The common non sense is having Scrum master, Team leader, product owner and one or more Project managers. Project manager and team leader are redundant roles in Scrum.

  • Guy assigned Scrum master role is not doing Scrum master. Scrum master solves impediments. Anything that disturb team is impediment which must be solved ASAP. The most common failure is assigning this role to developer without any previous experience with Scrum. This role partially replaces common project manager but Scrum master is without power over team and Scrum master doesn't demand any features to be implemented. Scrum master guards the team even against Product owner with unrealizable requirements.

  • Guy assigned Product owner role is not doing Product owner. Product owner has financial responsibility for the product. It is very specific and a key role to success. The role has something in common with analytic, project manager and product manager. Product owner collects and maintain requirements (usually in form of user stories). His responsibility is providing information to the team and defining priority of user stories. He should be on site with the team because cooperation between PO and the team is continuous.
  • Changing process name to Scrum but leaving most of the process as it was in the old way. The most common scenario is that you will change from waterfall to Scrum and the most significant change is that you do not do analysis and documentation any more and you say that you Scrum.
  • Requirements / user stories are missing definition of done - very common. If you don't have definition of done (acceptance criteria) you cannot make any assumption about complexity of user story during sprint planning. If you don't have them during sprint you cannot mark user story as completed because you cannot validate it.
  • Quality is considered as optional. Quality in Scrum is first class citizen. We can say that each acceptance criteria should be covered by automated end-to-end test. Once you start reducing quality and adding untested features you are losing control over the product because features considered as done can stop working any time due to regression.
  • Result of the sprint should be shippable increment (= working and tested) to the product.

Edit:

I'm adding important note. When using agile approach the main point is delivering the highest amount of business value to the customer as fast as possible. But the customer (represented by Product Owner) describes what is the business value. So it is not generally true that you don't have analysis or documentation when using Scrum. If customer requests analysis or documentation and mark it as business value (for example because of large scale or long term project which should be improved in next several years) you will create it as well. The most basic approach is including analysis and documentation in acceptance criteria for user stories. Analysis in such case is documented communication with the product owner in some standardized way.

Ladislav Mrnka
  • 7,326
  • 1
  • 23
  • 32
  • I like your focus on *continuous interaction and communication*. Some of the concerns I hear are about missing details in stories or undocumented decisions (even about technical details) and people want to protect against the effects of wrong decision (a very defensive point of view). – cringe May 06 '11 at 11:18
  • 2
    The documentation and analysis is replaced with continuous interaction and communication. You can't remove one and don't introduce the second - it will exactly cause missing details and wrong decisions. – Ladislav Mrnka May 06 '11 at 11:20
  • `The most basic approach is including analysis and documentation in acceptance criteria for user stories.` That is my initial reaction too. If the story has acceptance criteria, that's the best documentation you can have. But if the team decides to create some additional documentations (think of READMEs in the trunk or a wiki with useful information), then I don't see a problem. I think people fear that SCRUM = nothing is ever written down. – cringe May 07 '11 at 06:36
10

Biggest problem is always buy-in. If any team, or key individuals haven't bought in (project management, QA, development, etc) then failure is almost assured.

Another related problem is actually making everyone involved aware of what scrum actual is and what is not.

I've seen environments where project management has actually taken this as a ticket to come directly to developers with changes and expect it to get done tomorrow, since we are using the great new process. Anyone that has been in this situation or in other failed attempts at implementing Scrum and have a bitter taste in their mouths. These people sometimes will try to de-rail the project as well.

Another problem I've seen is stand up meetings. You will always get the guy that wants to sit down during a stand meeting.... "I've got a bad back" or whatever. It always seems to be the same guy that has no idea what the objective is behind the standup, and will not shut up about politics or what he did that weekend. Stand up meetings, I have found, are the key to effective communication. It is important not to let anyone poison these meetings.

aceinthehole
  • 2,388
  • 4
  • 18
  • 26
  • 1
    Just tell Bad Back Boy to stand while talking. If he still complains, make an announcement that there are doughnuts in the kitchen. – JeffO May 05 '11 at 21:15
  • `management has actually taken this as a ticket to come directly to developers` That's a good example of a situation where the SCRUM process is not understood, right? That the team can not accept new stories in the middle of a sprint. – cringe May 06 '11 at 10:10
  • @cringe, yes ... exactly – aceinthehole May 06 '11 at 11:19
  • 3
    does it *really* matter is someone sits instead of stands? Seriously? This is why agile methods don't work - people adhere top more rules than they did in the old process-laden methods! – gbjbaanb May 06 '11 at 12:59
  • 1
    @gbjbaanb Ultimately it doesn't matter. Do you know what standing prevents though? And if so, how do you try to prevent it? And is it working for you? – Julio May 06 '11 at 15:36
  • @gbjbaanb Although there has been research indicating that people make at least the same quality of decisions in shorter periods of time while in a stand up meeting (http://psycnet.apa.org/index.cfm?fa=buy.optionToBuy&id=1999-13895-011), you are correct, it isn't a huge deal if people do not stand up a priori. But it does go back to what I was saying about buy in. The characters that protest the loudest about standing up, in my experience, have been the individuals most likely to de-rail the effort... through apathy or spite. – aceinthehole May 06 '11 at 22:31
  • @Julio Standing solves nothing, my current team has one guy who comes to life when its his turn, like he's standing on a soapbox. Standing up does not *necessarily* keep things short. What does work for all meetings is a fixed end time. 15 minutes and you're out keeps people's minds focussed on time. Or get a stopwatch and tell everyone they have 1 minute. – gbjbaanb Jun 25 '14 at 07:43
10

The biggest problem I've noticed in over 10 years of xp and scrum, is when teams who don't quite "get" agile yet, decide to "be flexible about agile" and start customizing it, dropping certain parts, etc, without a clear understanding of what each part does and why it's there.

I've seen teams be more successful with scrum when they do things by the book at first, than the teams who change what they don't "get" yet.

That's when you get things like "first sprint, we'll do all the requirements. second sprint all the design, etc, etc, last sprint all the testing". Also known as waterfall. Or even simple things like "let's sit anyway, what's with this standup business?".

Something to do with Shuhari (http://c2.com/cgi/wiki?ShuHaRi).

Julio
  • 1,854
  • 13
  • 10
7

Trying to do all the analysis for the code we were developing in the same sprint we were actually coding it.

Kevin D
  • 3,426
  • 27
  • 36
  • And you needed analysis because the story was without the needed details? Or because the code wasn't clear enough and/or not documented with tests? – cringe May 05 '11 at 19:26
  • 1
    Effectively the stories were incredibly high level to the point where the product owner (my terminology is failing me here) didn't even know what they wanted. – Kevin D May 05 '11 at 19:33
  • We had this one too. Since then we've done most of the analysis parts before the sprint starts. – Carra May 06 '11 at 08:35
5

We moved to scrum a little while ago, and frankly the management running it treated each scrum as a 2-week waterfall process. There was such an adherence to the rules of scrum that is became a process in itself!

This is the problem I find, all agile methodologies should be about flexibility to work effectively the way that works for you. Not the way that is proscribed by the processes. For example, we had 2 week scrums, and a team said they felt 2 weeks wasn't enough to do good work (not with the downtime caused by the end of scrum demo and the initial requirements review) so they wanted to go to 3 week. Shock horror! Management refused because they'd decided 2 weeks per scrum was ideal and that was now documented in the quality procedures.

Scrum is the least agile of the agile methods, which is perhaps why its been so popular - its easier to sell to the old guard. you are supposed to remove stuff you don't like, but I don't think that happens. My advice is to go with a more flexible, less rules based one and add rules that you need instead. I prefer Crystal because of this.

Ultimately, just remember the half-arsed agile manifesto.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 3
    +1 for "scrum as a 2-week waterfall process". Unfortuantely that seems to be really common – DPD May 06 '11 at 13:35
5

The biggest problem is that also your client needs to accept the SCRUM process and become agile as well. Most of clients want to hear this at the beginning of the project:

  • How much it will cost
  • How it will look like
  • When it will be done

It sounds reasonable, but it's absolutely incompatible with agile. You need to explain to your client why is agile good for him instead of waterfall.

Ondřej Mirtes
  • 241
  • 1
  • 3
  • 2
    This is absolutely incompatible with any development methodology. You can never say this at the beginning. You must do analysis + some part of design to be able to specify this accurately but analysis + design can take half of the project time / budget and even after that you can fail because analysis is not something the client fully understands. – Ladislav Mrnka May 06 '11 at 13:22
  • But it's one of the big problems when you switch to SCRUM too. People are so used to this questions and answers that most of them don't realize anymore that most of the time the answers are wrong in the end. If the customer comes in with a rough vision of the product, he will ask `how much will it cost?` and they expect a detailed answer right then. My reply to this concern is always "if you exactly know what you want in the end, you don't need agile. Just code it down." But we all know that is not going to happen. ;-) – cringe May 07 '11 at 06:43
2

We had two large issues on my first go at SCRUM:

1) We didn't really have a product owner. Our boss had to play the role because no one who should have been product owner would agree to do so. This kind of put a crimp in things because he didn't always actually know the answers.

2) We were bad at accounting for outside components. Our first few sprints involved getting full automated testing up and running, and we repeatedly ran into trouble automating the simulators we were using. Somehow we never got any better at realizing that this was going to happen.

Michael Kohne
  • 10,038
  • 1
  • 36
  • 45
  • +1 for "not having a product owner". We ran into the same problem - sometimes it's unavoidable, but you should acknowledge it and plan accordingly. – sleske May 08 '11 at 16:18
2

The major problem I face in my project is that requirement gathering takes place after we haave estimated for the next sprint. We estimate based on the acceptance criteria. During the requirement gathering we find that the fine tuned AC is much larger so the task initaly estimated for 8 hours is now really 24 hours! So can I change my sprint backlog and revise the estimates adn reduce my stories? No sir! Agile requries that you cannot change the sprint backlog! Thats what my TL says. So shouldnt I also be coding as per the original acceptance criteria for which I had estimated the time as 8 hours! God! No! You cant do that! That wouldn't be Agile, would it!

DPD
  • 3,527
  • 2
  • 16
  • 22
  • How did you fix this? Or was it the reason that failed the whole introduction of SCRUM? I thought if the team gets more experience the sprint planning and estimate poker will reveal the missing requirements early on and the estimates will get better and better. – cringe May 07 '11 at 06:39
  • we havent fixed it yet. And we are still using SCRUM. The only difference is that if we say that the additional work is too much and the TL agrees, we can keep the story aside. We end up putting in more hours. – DPD May 07 '11 at 08:17
-1

Some of the problems I came across are succinctly summarized in this article by my colleague. I won't go into detail, he's done it much better than I could do.

  • goal misalignment between different Scrum teams
  • demotivation problems in large Scrum teams
  • technological decision in large Scrum teams.
lennon310
  • 3,132
  • 6
  • 16
  • 33
Miłosz Gałganek
  • 1