9 ms·
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then
by theworld572 7y ago
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly.
What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you discover that there is a whole area of code that needs updating in order to allow for your feature to be implemented. This adds on another week of work required.
In a common-sense based development team, what usually happens is the developer has a quick work with the project manager and maybe other devs who need to be involved and says "Hey, I've found out that we need another week to complete this feature because X needs refactoring, do you still want me to continue with this?" then the PM either says "Yes this feature is important, even if it will take another week" or "No, the feature is not important enough to be worth spending another week on". Its really not rocket science.
In SCRUM what usually happens is the SCRUM master will tell you that the rules say that we have already committed to a set amount of work this sprint and that extra week of work falls outside the scope so we should create another card for the extra work and consider this card blocked.
The whole idea of having a rule for what to do in that situation just seems absolutely crazy. Just do whatever makes sense! Its really not that difficult.
- taneq 7y ago> What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. The thing is, your story cards or whatever are meant to be a live document. You have the big meeting, the next day you realise that what you came up with doesn't work, you grab a coffee with your stakeholder and talk it through, come up with a new plan, and you change the card you're working on. Probably check with the tech lead first, but it's that flexible. > In SCRUM what usually happens is the SCRUM master will tell you that the rules say [...] This SCRUM thing sounds evil. > Just do whatever makes sense! Its really not that difficult. This is probably the best advice ever for any development team. Just do the thing!
- Tharkun 7y agoI think the OP is missing the point of scrum. The scrum master isn't supposed to tell you what the rules are. The rules are whatever the team decides they are. The scrum master is not the boss, they're supposed to be a facilitator...
- taneq 7y agoExactly. It's meant to be collaborative, not authoritative.
- theworld572 7y agoThat sounds like typical scrum-enthusiast double-speak to me! :D https://www.scrum.org/resources/what-is-scrum https://www.scrum.org/resources/what-is-scrum "This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together." Definitions, Rules, Roles, Artifacts etc. Sounds pretty authoritative to me. If it wasn't authoritative, how would you even know what SCRUM "really" is? You cannot say both that SCRUM is not authoritative and lets you do what you want, and then also say "you're not doing scrum correctly".
- empath75 7y agoAll of the rules say the team is allowed to change anything that doesn’t work for them. Scrum is a set of suggestions for organizing a team, it’s not Moses coming down with tablets from on high.
- mmcnl 7y agoWhy not try to find a perspective that will make things easier for you? You can look at any suggestion and shoot it down for reasons X, Y and Z - that's easy. Try to invest some time in finding out what works for you and focus on that.
- tootie 7y agoYou shouldn't actually ever change a story in progress if you can avoid it. The feature is the feature. How you build it doesn't go in the story. And if you aren't sure how to do it, you account for that in the estimate.
- Tharkun 7y ago> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a thing done. If and when it becomes clear that this feature is too complex, too big, or whatever, then it can be reestimated, or decomposed or reevaluated. It's supposed to be agile, not rigid and fragile.
- theworld572 7y agoWhats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business. Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and that a sizeable (if not the majority) amount of developers loath working in SCRUM teams. So wouldn't we just be better off if the industry ditched SCRUM entirely?
- taneq 7y agoIt's to keep everyone in the loop on what's happening in the codebase, and give people a time to ask for help on whatever's blocking them (so you hopefully get it sorted in a 10 second conversation instead of having to break their flow later to get help).
- ben509 7y agoThe "do what makes sense" is limited because you have to ask questions to ascertain what makes sense. Some questions are easy to answer, but many questions can only be answered by doing a thing that takes work. And Scrum gives you a framework that tries to put a limit on how much work goes by with no answers. So it uses a simple schedule. The team works for X weeks, working on implementing specific tasks. (Which in turn answer some questions.) Then the team stops, reviews their progress on the larger product, and adjusts plans accordingly. Now "do what makes sense" has demonstrably advanced.
- empath75 7y ago> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. They don’t, there are ‘spikes’ that are just time spent researching or exploring or designing rather than implementing. If your scrum master is telling the team what they can’t or can’t do, or how they should do their jobs, they are doing it wrong. Their job is to help you plan and help you resolve impediments to your work. They aren’t your boss. The first thing in the manifesto is people over process, there should never be a case where some rule tells you that you can’t do the right thing. Formal Scrum is a nice way to organize ‘normal’ work, but there are lots of cases where you have to improvise, and the process should never get in the way of that.
- GordonS 7y ago> If your scrum master is telling the team what they can’t or can’t do, or how they should do their jobs, they are doing it wrong Unfortunately in my experience this does happen quite often. I've found the biggest issue with scrum is when people (usually the scrum master and PM) take hard-line, dogmatic views of scrum processes.
- profalseidol 7y agoThere's this course in pluralsight that talks about two orgs that promote scrum. The other one seems to be giving out the wrong ideas. I think it's this one (copied from wikipedia): In 2002, Schwaber with others founded the Scrum Alliance[18] and set up the Certified Scrum accreditation series. Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org which oversees the parallel Professional Scrum accreditation series.[19] I think it was Scrum Alliance that's giving out ideas like Burndown chart is required in scrum.
- tootie 7y agoYou never just write a story on the spot for a feature. It has to come out of completed design work that takes as long as it takes and ideally is funnelled through the same pipeline as you use for development.