5 ms·
I agree with author... instead of doing "Scrum", how about we act like adults, and speak with people when we need to, in respect to their time, schedule accordi
by scalatohaskell 9y ago
I agree with author... instead of doing "Scrum", how about we act like adults, and speak with people when we need to, in respect to their time, schedule accordingly, and not clown and parade around with scrum and poker cards.
http://programming-motherfucker.com/ http://programming-motherfucker.com/
- matthewmacleod 9y agoUgh, this attitude is just the worst. There are a whole bunch of legitimate reasons that aspects of Scrum are useful to some teams. Like the planning poker thing –I work with a team of talented, experienced and professional developers, and we still have misconceptions about complexity that are revealed by the planning poker approach. The idea that 'if everyone just programmed it would be fine' is totally asinine.
- scalatohaskell 9y agothat's not how I meant it. Sure, plan it, however it suits you and the team. If planning poker works for you, great. But do you need to coat it under "Scrum", having special moderators such as Scrummaster and consultations every year how you are not doing scrum "enough". I don't advocate programming anarchy, but I don't like when managers treat programmers like some woodchoppers that they need to wrap fine grained process around, instead of having the team work the way it fits them best.
- matthewmacleod 9y agoI completely agree that 'agile' without being agile is just buzzword bingo, and I've been through it myself. Ultimately, plan however works for your team. But I do get the impression generally that there can be a lot of unjustified resistance to any kind of organisation among certain groups of developers; it pays to be open-minded about techniques that can work.
- scalatohaskell 9y agoI think the resistance is not unjustified - mostly programmers are fed up with "these" things, since they always get misused against them (i.e. - estimations - you and me know how it works, that it's well, estimation - but in back there is manager who translates it in his excel to $$$ and time, and the second your 8point story is now day overdue you are being pushed to zones which only further damage the project down the road (costs which you will have to pay by overtimes, not the guy behind his excel). Does that mean estimation is bad? No. It's non-programmers who misuse it. Would team be better without estimation? Probably, since it wouldn't be misused by external elements, and we could just do our damn job). Perhaps the original agile was meant correctly, but as of today most organisations just use it to justify and coat (perhaps) same things agile was to be against. For me today Agile has so way too many faces. If it doesn't work, answer is always "you're not doing agile/scrum correctly). There are always reasons how you're not being agile enough, no matter how many times you fine-tune your "agile" on retrospectives, if there are managers and people misusing it against you, you could as well be better without it. What an incomprehensive piece of text I wrote. Sorry. I'm not native English speaker. If you're lucky non of this applies though, but you have to be lucky enough to work with lots of (prehaps we might say all) smart people across whole "chain of command".
- Chris2048 9y agoWhen they ask for an "estimation", they are actually seeking a "quotation".
- deleted 9y ago[deleted]
- mattmanser 9y agoAny links to those studies? Although don't think we're interested in scrum vs waterfall. We all agree that iterative development is better than waterfall.
- fastbeef 9y agoYou ask us to be adults and then finish it with _that_ link?!
- Shengbo 9y ago>We are tired of being told we're socialy awkward idiots.. Well in that case I sure hope you're not planning on wearing one of those t-shirts...
- scalatohaskell 9y agoIt has some truth to it - any extreme (micromanaging with "agile" buzz) will generate opposite just as extreme pole
- good_gnu 9y agoYes, but if everyone speaks to you whenever they need to, you might be interrupted in your work very frequently which can be stressful. If only people could communicate all of these issues say once a day or so...
- scalatohaskell 9y agoYes. And at that point, you will suggest, like an adult, to speak when it fits both time. I wonder how people who don't use Scrum solve this problem! Here's little experiment. 10mins after standup is over, ask some people what did they learn in standup. I mean specifics. Noone will know or care or remember. Sure, people get broad picture, which they could just as well by looking onto jira or whatever.
- ryandrake 9y agoI've worked at one of these "no software process" utopias, where programmers just sat in their own world programming away and guess what? Software barely got released, it was always late, low quality, and nobody from management to individual contributors had any big picture visibility whatsoever. It was a total circus. They didn't even use source control or have a bug tracker. Absolutely 0/12 on the Joel test. I was brought in to provide some adult supervision and you better believe I layered on the process. We made a little progress, but unfortunately, you can add process but changing culture is much harder. At the end of the day I got quality and release cadence under control, got a roadmap and a spec together, got basic "table stakes" software infra and tools up, but boy were those first few months a nightmare. I can't imagine any business getting anything done with just "programmers programming".
- lawnchair_larry 9y ago> "I've worked at one" I mean this in the nicest possible way. Your experience counts for nothing. It's a one-off. Literally. > I was brought in to provide some adult supervision > I can't imagine any business getting anything done with just "programmers programming". Your attitude and your arrogance will definitely limit your ability to lead engineering teams. Talented developers are not going to work with someone like you as long as they have a choice. I do recommend taking a coding bootcamp type course and delivering a project to gain a better understanding of how software projects work.