I think the deeper reality is that people just suck at working together. There is always gonna be friction when a group of individuals try to achieve something together (time lines, slackers, miscommunication). We blame it on method X when at the end of the day its human nature and no magical method of working can completely remediate that.
Scrum is a cancer
371–380 of 486 posts
Re: Scrum is a cancer
#372Earlier quoted context omitted.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement. But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master…
I'm reminded of Ben's question about the shamble-men in The Name of the Wind [0]. It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them. In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fai…
> It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them.
“Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, worth pursuing in more detail, especially for people who have some influence over substantive development methodology choices, rather than only having a choice of whether or not to avoid some place that is imposing a thing that they call “Scrum”. (And, really, you should probably steer clear of any place where being in the dev team gives you no input on substantive methodological decisions irrespective of whether what is imposed is called “Scrum”.)
Re: Scrum is a cancer
#373Earlier quoted context omitted.
Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.
The movie came out the same year all my friends and I graduated a Software Engineering degree. I love the movie, but damn it hits close to home and I never know if I should laugh or cry.
Silicon valley started the year I entered the tech workforce. Very similar feeling.
Re: Scrum is a cancer
#374In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…
> I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now). And that was your big mistake. Those are real concerns, but those things are abstract and non-qu…
> The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
I do not understand how this is possible.
* Sprint planning: 2 hours
* Sprint review: 1 hour
* Sprint retro: 1 hour
* Daily stand-up: 15min / day
On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.
What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
Re: Scrum is a cancer
#375Earlier quoted context omitted.
This wasn't scrum because talking to the costumer is the primary job of the Product Owner and not of the Scrum Master. PO is also a full time job and not some side hustle of a team lead or SM. Having a good Product Owner makes the difference between adopting scrum successfully or failing at this process. Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple -…
I honestly can't tell, because you don't have a history of joke comments and didn't include a /s. Is this intentional parody, or did you miss OP's closing line? > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
His point is not exactly invalid though?
If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail?
Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time just managing scrum. Something in scrum not working throw it out. Do not double down and add more.
Re: Scrum is a cancer
#376In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…
> I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now). And that was your big mistake. Those are real concerns, but those things are abstract and non-qu…
Not that I disagree with you, but I read your message as: "managers suck, so I found a way to work around them".
It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.
Re: Scrum is a cancer
#377Earlier quoted context omitted.
I'm reminded of Ben's question about the shamble-men in The Name of the Wind [0]. It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them. In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fai…
> It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them. “Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, w…
I'm not suggesting that "don't call it Scrum" be the final word in software development methodology.
I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate.
By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
Re: Scrum is a cancer
#378Earlier quoted context omitted.
Ah yes the defence: "The process failed because you didn't have enough project managers on board" No the process failed because it was fucking shit and everyone went somewhere else. The only good thing heavy processes are for are propping up employment statistics.
Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.
I haven’t seen it yet surprisingly. I will watch it tonight.
Re: Scrum is a cancer
#379In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…
Scrum master name is supposed to be joke, like dungeon master. They are supposed to lead the process of scrum and stay in the background.
Re: Scrum is a cancer
#380In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement. But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master…
So, would it be fair to summarize this as, "You weren't doing True Scrum" ?