Live data from Hacker News

Why I'm done with Scrum

lostechies.com

71–80 of 163 posts

Re: Why I'm done with Scrum

#71
post #27
post #16

Earlier quoted context omitted.

I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.

That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.

Isn't that just a No True Scotsman argument? You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project. Well, OK, if that's your defintion of "Agile".

But the "Agile" (rather "Scrum") described in books and web videos and blog posts isn't like that at all. It has become a decidedly "heavy" process with all sorts of jargon behind it. My guess is that this is what the linked post was talking about, and not your "Agile==good" metadefinition.

Re: Why I'm done with Scrum

#73
post #27

Earlier quoted context omitted.

That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.

Here is another perfect examplee of what's wrong with SCRUM, it creates zealots. When someone starts talking about a need to give good, self-disciplined devs a little freedom instead of micromanaging them to death the scrum zombies start shouting about "cowboy programmers". When someone starts talking about long-term or strategic planning they start screaming about "waterfall". The truth is that there is a lot of evi…

Good developers+zero formal process only works to a certain scale, though. I think that's where scrum might have a place, just enough process to keep things from going off the rails when the team is too big to self-organize over a long period of time.

Agree about the danger of zealotry though. Also, the vocabulary is just so ridiculous - I have to mentally think "black dog grooming" when I say "backlog grooming" just to keep my self-respect.

Re: Why I'm done with Scrum

#74
post #47

Earlier quoted context omitted.

In my experience most teams do planning completely wrong. The goals of the planning meeting are simply: 1. Do a relative-size estimate the top n stories in the backlog. (Where n is some number slightly larger than the number of stories that usually fit in an iteration.) 2. Pick the stories to complete in the iteration. That's it. I often see teams: * doing one-by-one story estimation, and debating over how many point…

I think the reason this happens is because no matter what people say, the idea that if you can't finish a story within a sprint it will simply slide into the next one is anathema. People spend more time on estimation when the consequences of mistakes are higher. If you can't realize that a story is larger than you thought and reprioritize mid-sprint without it being equivalent to missing a deadline in your old model,…

I agree, but I think some of the pressure for accurate estimates come from managers wanting to track employee time.

I had a manager that would pretty much go through the board and ask who did what card so he compare the estimates to the actual time.

Re: Why I'm done with Scrum

#75
Every time I come across "why scrum sucks" articles like these I can quickly point the problem: the ScrumMaster.

#1 - Iterations are less efficient than pull-based approaches: A good ScrumMaster keeps an eye on the burndown chart and negotiates with the stakeholders and team to either add or remove tasks from a sprint. My first sprint ever as ScrumMaster, we estimated a 3 months project, we did everything in 2 sprints (1 month)

#2 – Iteration planning meetings were wasteful: You are doing them wrong. A good scrum master keeps everybody focus on one user story at a time and keeps the meeting moving. I use a 3 min stopwatch in my phone. The whole meeting should not take more than 1 hr (I do 30-45 mins estimate new stories, the rest to plan and commit team to next sprint)

#3 – Scrum is highly disruptive in established organizations: A good scrum master servers as a bridge between traditional management and keeps them out of the team's backs. This one is the reason I don't like being ScrumMaster anymore. A good ScrumMaster needs great people skills, I rather write code.

Re: Why I'm done with Scrum

#76

When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well. 2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too mu…

Agile should also be subject to Agile. I like to think of it in terms of the Viable System Model in which the system has the potential to change itself based upon feedback. Put another way - make sure your implementation of Agile/Scrum supports tail call optimization and macro expansion or face the reality of being stuck in BlubScrum.

Agile is a toolbox of best practices and tricks. You need to use the ones that make sense. That is formalised in methodologies like SCRUM by doing a retrospective after each sprint.

For inexperimented teams, it is a good idea to start with out-of-the-box scrum and remove/replace bits that are not working out for team after a while.

For experimented teams, you just start with just a daily scrum end of day and add bits as you go along. (effectively start with 1 day iteration)

Re: Why I'm done with Scrum

#77
I read through the first bunch of these comments and scanned the rest...you guys, you guys... I might have missed it but I didn't see anything about client delivery that is viable...or do you have other reasons for being in the software game? Who really cares what process you use? As a client I want to be involved, I want to see how you're doing on an on-going basis, I want stuff that works well, I want stuff I can use and I want to alter by vision as you deliver because my business can change...

Re: Why I'm done with Scrum

#78
post #71
post #27

Earlier quoted context omitted.

That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.

Isn't that just a No True Scotsman argument? You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project . Well, OK, if that's your defintion of "Agile". But the "Agile" (rather "Scrum") described in books and web videos and blog posts isn't like that at all. It has become a decidedly "heavy" process with all sorts of jargon behind it. My guess is that this…

"You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project."

Well, that's kind of true: http://agilemanifesto.org/

You are mixing scrum and agile.

Re: Why I'm done with Scrum

#79
post #5

Earlier quoted context omitted.

Scrum is focused almost exclusively on delivery. Every sprint, you should be delivering working features. It's not that hard: every sprint, you commit to a set of stories to finish before the next sprint. Every day you meet briefly to tell everyone how you're progressing and to air out any impediments. That's about it. To me, scrum is stripping process down to the bare minimum you need to be effective.

I've never done formal scrum, but I've worked on a lot of teams, and I just don't see how there is a single bare minimum you need to be effective. In my experience, even with excellent teams, this depends on the project and the talents of the contributors.

To me, the bare minimum for success in software development is clear direction, continuous communication, and continuous verification of the product. Scrum is a simple process to ensure that all three actually occur and aren't merely good intentions left up to individual discretion. I guess you could come up with alternatives, but it would be tough to make it much simpler and still cover all three.

Re: Why I'm done with Scrum

#80
post #61
post #57

The problem with SCRUM is that it is not agile. That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results. I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity. You start to see and talk…

Can you elaborate on why Scrum is not agile? You are the first I read claiming this.

tosh has replied already, but I'll offer my explanation as well: Scrum is not Agile because it's all about ceremonies (the planning meeting, the daily standup). The only ceremony that brings some value to the project is the retrospective.
Post reply on HN