311–320 of 329 posts
Scrum is micromanagement. I think it’s as simple as that.
on the contrary: you have a PO in charge of communication and priorization of features and a dev team in charge of developing- no manager on top...at least in theory...
Scrum is a communication contract between customers / stakeholders, managers and dev teams. It is a poor cure for social and managerial dysfunction, but it is a cure. Scrum is a problem when it is mandated and imposed on functional organisations that do better and more fluid communication. This is often done as a way of flexing corporate power and does huge damage. A key problem is that we do not have ways of auditin…
Of course we have ways of doing that - one is the code quality, another one is historical performance on agility.
Earlier quoted context omitted.
Nope, never. I have seen more success in cases where teams estimate for 90% percent confidence instead of 50% confidence. By that I mean "it should almost never take longer than that" vs. "it will probably take that long." Unfortunately, to do that, you need enlightened business management that appreciates the difference between an estimate and a promise, as opposed to business management that pays lip service to the…
> "it should almost never take longer than that" vs. "it will probably take that long." This sounds like a much better way to estimate. Do you have any links to content discussing this?
I haven't seen a good way to turn the concept of "it should almost never take longer than that" into a concrete process. I've always seen it as a gut check, often implemented as "take your initial estimate and double/triple it." What I actually see is that a lot of teams implement that but walk back the doubling when the business/PM delegation persistently asks for more in less time. Only in really engineer driven cultures have I seen engineering teams successfully push back.
Earlier quoted context omitted.
I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.
If you do this often enough. People will assume you are busy if you don’t show up at all.
To think of scrum as a process is wrong. It's actually an organizational pattern language. The idea is that social interactions are a complex system and there are patterns of interactions which, from experience, seem to work in certain contexts. http://www.scrumabok.org/ It's not even software specific. Which is actually a strength. Example, one common misconception is the daily standup is a status meeting. In fact y…
No. Agile is a subset of TPS (toyota production system)/Lean applied to software.
Earlier quoted context omitted.
I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.
That seems to be secret for managers anyway. Always appear eager and motivated and then run away.
That's it. (Ok, once a year they do reviews.)
[0] If they don't bug a dev to do it.
Earlier quoted context omitted.
Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybr…
One thing about agile is that usually companies not only set fixed deadlines but also fixed feature set; which usually means lower quality. That in turn means technical debt; which puts future deadlines and feature sets at risk. Since in SCRUM as a team you try to not compromise on quality the only way out of this is to push back on deadlines or feature set (or both). So instead of blindly executing orders; the devel…
Earlier quoted context omitted.
Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…
Scrum is unsuited to actually building a decent framework for you application. We tend towards 4 or 5 sprints in which nothing is completed, only to suddenly have a flood of completed things the next.
It's perfectly possible to deliver small units of work weekly. One still gets frameworks while doing that. It's just that the work of making the framework happens over time, not up front. Which is good, because good designs are based on good information, and the beginning of the project is when you have the least information.
Earlier quoted context omitted.
It's similar at my office. We also use it to let the rest of the team know on occasions when you're blocked on something.
Why wait until a meeting to air that you are blocked, just sort it out when you become blocked. Where is the agility?
Earlier quoted context omitted.
By breaking it down into smaller stories?
That would be ideal, but we are devs, we don’t get to touch the stories other than to mark them as done...