We started doing Scrum around a year ago and it has worked well for us. I feel some of the points described in the article about Scrum are not because of the framework itself but because there could have been a lack of a Scrum Master, which is an important piece in the puzzle, to ensure Scrum effectiveness.
Why I'm done with Scrum
51–60 of 163 posts
Re: Why I'm done with Scrum
#52just code. code well.
1) code is minor part of delivering software that customer is willing to pay for.
2) "code well" is such a broad affirmation as to include using Scrum/Agile/something else to ensure that the code we deliver, works, is what customer wanted, when they wanted it, and cost < revenue.
Re: Why I'm done with Scrum
#53The #1 point mentioned in the article was my experience as well. For a tight deadline project if we decided to do everything based on the complexity points and team velocity it would take 6 sprints and a total of 3 months. But we just decided to ditch it and sit around a table and finished the whole thing in 2 weeks straight. So my experience is that if you are working with a dedicated team it is better to finish the…
How would Scrum turn a 2 week project into 3 months? Are you just saying you were terrible at estimation, or what? I don't understand what you ditched, specifically, and how that produced an improvement.
In timeboxed iterations, you have to be very careful that work doesn't expand to fill all available time. If you are a little conservative with your estimates, its easy to double the time the necessary aspects of development would take. Little, unnecessary tweaks becomes more important than putting four hours into the stretch goal that is going to spill into the next sprint.
Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.
Re: Why I'm done with Scrum
#54When 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…
Agreed. When you don't have collective excellence anymore, you are left with process.
Re: Why I'm done with Scrum
#55Earlier 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.
You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.
What does QA look like with continuous delivery?
Re: Why I'm done with Scrum
#56The effectiveness of scrum really depends on the team size. The larger the team, the more bureaucracy is needed to manage it.
What's a good team size?
"Fewer than three Development Team members decreases interaction and results in smaller productivity gains...Having more than nine members requires too much coordination." - Scrum Guide, page 6
Source: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru...
Re: Why I'm done with Scrum
#57The 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 about the flow of value, what's next, what's in the moment ("what can we do right now?). You see context. All of that is missing with SCRUM or only possible with a highly motivated and responsible team that communicates a lot automatically.
I'm not yet saying that kanban is solving the software crisis [1] but it turned around quite a few teams that I've seen and been part of.
DISCLAIMER: I'm working on https://www.blossom.io which is a lightweight kanban board.
Re: Why I'm done with Scrum
#58FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum. And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and th…
> What if someone else has an important piece of information that the dev and the architect don't?
That isn't good enough justification. You are too much erring on the side of caution.
Re: Why I'm done with Scrum
#59> Iteration planning meetings are seriously expensive. I completely agree on this one. I've worked in several corporate environments utilizing Srum and the planning meetings were always a huge waste of time. I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does Scrum/Agil…
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, it's not going to work. In my experience this is the key failure mode of scrum.
Re: Why I'm done with Scrum
#60When 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.