91–100 of 163 posts
I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire…
Earlier quoted context omitted.
In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.
If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.
This strategy falls flat when the PM committed to a stakeholder that they'd get a feature done without defining it well or resolving dependencies, so now we have to sit for 15 minutes hammering it out.
Note that I'm not totally disagreeing, but textbook scrum and what-happens-when-people-spend-a-lot-of-money-to-develop-something scrum often diverge greatly.
The ultimate business purpose of scrum is to manage expectations. What's going to be done, when's it going to be done, if something's stuck who is responsible, etc. If the PM starts making wild promises and setting crazy expectations -- which PMs are wont to do -- all the methodology in the world isn't going to save you.
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 know that no company ever wants to think of itself as "big and established", in fact my previous company had been around for 13 years, had hundreds of millions in revenue and almost 1k employees and they still liked to pretend they were a disruptive startup.
Earlier quoted context omitted.
In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.
If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.
A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story.
* - whatever will give you 6 +/- 3 months
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 sprint…
And we're still recommending companies adopt this, when the failure rates are both known to be high, and catastrophic when they occur?
The 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?
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.
If you're still learning how to do things, then how-tos, recipes and best practices like Scrum will help.
> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously ex…
> > With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, > No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. Of course there is. There is no burn-down, no 'time', without tasks. So while in a pedantic sense you're right that you commit to 'time', time is measured in stories.
Earlier quoted context omitted.
> > With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, > No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. Of course there is. There is no burn-down, no 'time', without tasks. So while in a pedantic sense you're right that you commit to 'time', time is measured in stories.
Time (of stories) is measured in points. You won't be talking about a 10 story sprint.
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.
No it's not. It's pretty well documented in the scientific literature that making people who've mastered something (eg. doctors, airline pilots) work from intuition a lot of the time, so following a set of prescriptive rules inhibits their performance. If you're still learning how to do things, then how-tos, recipes and best practices like Scrum will help.
"The Checklist Manifesto: How to Get Things Right"
http://www.npr.org/templates/story/story.php?storyId=1222261...