21–30 of 163 posts
The effectiveness of scrum really depends on the team size. The larger the team, the more bureaucracy is needed to manage it.
True. My last project started each day with 2 hours of scrum.
What? Was your 15-minute stand-up 2 hours long? If so, are you sure you were doing it right?
Were you scrum-master, and doing 2 hours of admin per day?
What were you doing for the rest of the working day?
I'm not really sure what you are describing here.
The #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…
The author is right that, with scrum you end up focusing more on process and not delivery. There are nice things about scrum, but I think scrum followers are too doctrinaire. It has some well-defined practices and is associated with that agile "manifesto" that you are compelled to buy into if you adopt scrum. Being doctrinaire about anything is guaranteed to distance you from reality - you give project managers a wea…
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.
Agile is a philosophy, Scrum is meant to be more of a framework to implement that philosophy, but many people treat it as a set of rules on how to do things, which tends to violate the philosophy of Agile process in the first place.
Scrum is, for many development organizations, an incremental improvement over what they are doing now. The biggest problem that I have with Scrum (and all prescriptive methodologies) is that it's presented as a vision for the right end-state instead of a set of tools that you can use to help find the right process for your immediate context.
Earlier quoted context omitted.
True. My last project started each day with 2 hours of scrum.
> started each day with 2 hours of scrum. What? Was your 15-minute stand-up 2 hours long? If so, are you sure you were doing it right? Were you scrum-master, and doing 2 hours of admin per day? What were you doing for the rest of the working day? I'm not really sure what you are describing here.
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…
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.
"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.
But our meetings are short. 5 or 10 minutes max. If you're getting bored than, to quote another commenter here, you're doing it wrong. Quick summaries, major problems, then get out the door.
The effectiveness of scrum really depends on the team size. The larger the team, the more bureaucracy is needed to manage it.
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.
As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can actually add value. Good programmers are that good.
[1] I've fired every cowboy coder that ever worked for me except one.