51–60 of 387 posts
Practice and experience may have led to this conclusion, but it will be good to know that the (original, Scrum-defining) Scrum Guide, http://www.scrumguides.org/scrum-guide.html, doesn't even mention nor defines "story points". Obviously, there is planning and estimation involved in Scrum, and story points can be a metric used for "amount of work"... but it's not a defining feature.
I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…
Why can't we make some sub-component this sprint then the UI bit the next?
I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.
This talk about agile by one of the founders was posted on Hacker News a while back, it is good, and I think complements this post: https://news.ycombinator.com/item?id=11548334 To summarise, the issue Dave Thomas has with agile is that it has become a prescriptive framework, 'Agile' (with a capital 'A'), rather than what it originally started out to be, which is a means of being agile (small 'a'). I really liked thi…
I am guessing that such an environment is quite rare, hence the percieved lack of utility of the retrospective.
I can speak from experience that this is very hard to do. I expect that I will have to deal with a brewing technical conflict in the team soon and I'm not sure what's the best way to do it. I've also seen what happens if such coflicts are sweeped under the carpet and it's not nice.
After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy write this article.
Deconstruct Scrum and perhaps something like RUP/DAD (Scrum doesn't tackle the whole lifecycle) into components and understand what the purpose of each component is. Start from Kanban and add stuff until you get a process that matches the critieria of the organisation. This requires a lot of skill though, so many teams are stuck with one-size-fits-all tools like Scrum, especially now that it's become a management buz…
I like how Scrum promotes transparency and trains each individual to become self-managed (or at least getting better at it). But it often feels like it's being hyped up, with many people getting obsessed over its practices/rituals. Estimating work is a nice idea, but using 'story points' for it just feels like a bad API decision - I have never seen a new Scrum team member (including me) getting it at 1st try. And may…
I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…
Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resem…
In my opinion, the good thing about Scrum is that you can tweak the rules to fit your needs, aka, "Scrum in name only". The daily standup, IMO, should be only to remove impediments, and if you have none, then a sentence or two will suffice. I see the DS as the most useful meeting, as you are aware of what your workmates are doing. And if Scrum is still a pain in the back, then you have Kanban, which is sort of Scrum…
This kind of tweaking is frowned upon and you will be chastised for doing it. Yes you can do it (and probably should when you understand the purpose of each Scrummy practice), but don't expect to be praised by Scrummers.
I'm extremely happy to discuss the reasons I want to change something, but all to often the only counter-argument is "that isn't Scrum". I'm 100% fine with that, but I'm not going to do something if the only reason for it is religion.
Earlier quoted context omitted.
Describing drawbacks and problems is value added. Theoretical physicists regularly know about problems for decades before solutions are found. Precisely describing the problem can get the intelligent diaspora organized around finding improvements to the situation.
Did you just compare a project management methodology with theoretical physics? Sounds to me like you try to compare apple with orange. Sorry, I don't follow you.
A more relevant example would be The Mythical Man-Month. In many ways, agile and scrum are iterations on solving that problem: project-based knowledge work is hard to estimate and challenging to scale in certain ways.
Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an…
>>> Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else There's slightly more to it than that: it also encodes an assumption that you're working with a single fairly-tightly-integrated group (with synchronisation points at least daily). It's possible that this helps with estimation and scheduling -- it's a lot less clear that it helps get the best outcome…