So it wasn't scrum. It was just bullshitters using the word and doing what they wanted to do anyhow.
No True Scotsman?
That argument can be used either way around so it's fairly useless.
In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them.
It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for something that's going to turn out to be crap in the end.
In 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…
What (or who) made them decide they needed scrum in the first place?
IME, it's usually a new hire, usually a product person. There's always pressure on those people to introduce changes to increase whatever the KPI metric is, and from their perspective scrum is a great choice. Plus management drools over data/metrics, no matter how much you explain to them that there are serious flaws with the data. You get more of what you measure, and the law of unintended consequence can be a beast. I've seen people come under the Eye of Sauron because they weren't closing as many "story points" as their peers. In reality it's because this person was the best mentor on the team, and the most experienced in the codebase. They spent most of their time pairing and training others, but only one person gets to make the commit and claim the points. That person initially stopped helping people and would (understandably) get irritable when asked questions, and then left the company. Management considered it a win to dispense with a "low velocity" engineer. It hurts my soul to think about the stupidity, especially since they were told numerous times that this person was the MVP of the team, no matter what the metrics said. You get more of what you measure.
At my previous job, the "daily stand up" never lasted less than 30min, and often times went to 2 hours. Also, I didn't just have one "daily stand up" but two! One with multiple teams, and one with just our team because our manager really wanted to silo our work and ignore as much as possible other teams (especially QA for some bizarre reason). Yes, we weren't doing "scrum" right, but like communism, no one does it ri…
We manage short standups most of the time - why didn't you tell the manager to shut down after 15 minutes? All these agile processes require the team to take some responsibility and have some courage.
First, there was major miscommunication on the part of the new management [1] and who I thought was my manager wasn't [2]. Second, I was raising the alarm that the "agile and scrum" methods weren't working, and got it raised to a VP of the company [3]. He was let go. Did I cause him to be fired? I don't know. All I know, the new VP just said "that's a shame" when I brought up my points. I knew then, it was time to go.
[1] The silliness didn't start until new management took over.
[2] The term "team lead" meant "manager". I didn't get the memo.
[3] I was regularly talking to him at least once a week. He didn't want me to leave the company and to give him time.
In 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…
You're surely getting downvoted and lumped as one of the "but that wasn't real scrum" types, but this strikes me as unfair. I am highly critical of scrum, and have had many of the "that's not scrum" variety dismiss criticism, but yours is actually thoughtful and (indirectly) makes a good point: some people really do deviate from "real scrum" substantially. I hate scrum with a passion, but if we just do the inverse argument of blanket dismissing any criticism under "oh you're one of those" then we're being as intellectually dishonest as the "that's not real scrum" crowd (and for the record I don't include you in that crowd).
I appreciate you being willing to articulate an unpopular opinion :-)
> 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" ?
Yes I think so, but GP did point to actual specifications as justification. I hate the "you weren't doing real scrum" replies, but I don't think GP was doing that.
> 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…
50%?? Scrum is like a 1-2 hour planning/retrospective meeting per fortnight plus 10-15 minute standups every 1-2 days. How could that possibly take 50% of your time?
I once had twice weekly refinement sessions 1 hour each. twice weekly grooming sessions one hour each. daily standups 30 minutes, weekly planning 2 hours, weekly retro 2 hours. This was industry standard according to the consultants brought in with mckinsey to train the whole company. 10.5 hours before any other technical meetings,
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 ju…
> if you go into something with the intention of 'this sucks' and then do not even want to make it work we can rephrase this as "the serum didn't work because you didn't have faith in it."
No. The doctor told you to take care of yourself but you went to McDonald's again.
People are stuck in their ways and don't actually want to try anything new. That's why management always fails- you can't manage people.
> if you go into something with the intention of 'this sucks' and then do not even want to make it work we can rephrase this as "the serum didn't work because you didn't have faith in it."
No. The doctor told you to take care of yourself but you went to McDonald's again. People are stuck in their ways and don't actually want to try anything new. That's why management always fails- you can't manage people.
> People are stuck in their ways and don't actually want to try anything new
Those damn people. Business would go so much better if you didn't have to hire them /s
> if you go into something with the intention of 'this sucks' and then do not even want to make it work we can rephrase this as "the serum didn't work because you didn't have faith in it."
Expanding on that, scrum is a religion. Like many/most religions, it requires faith, and that a lack of faith is singularly responsible for any failure of said belief/religion to deliver its promises.
I agree completely about scrum being a religion and lack of faith and all that, and I can't stand the "but that wasn't real scrum" automatic response that most of the defenders make.
But the GP point is valid. not every iteration can be blamed on "scrum" anymore than anything bad that happens in life can be blamed on Satan. If people want it to fail, they can make it fail.
But that said, to slightly counter my own point: I think that demonstrates a weakness with Scrum. If people following the system (even malicous compliance) can make it fail, then the system is flawed. It obviously sucks for those people or they wouldn't have a bad attitude about it. For example, Scrum likes to pretend that all engineers are fungible, but this is clearly wrong and a big problem with the system.
Our 15 minute standups were about an hour, sometimes longer. The project manager aka scrum master spent at least 80% of those minutes talking. They were scheduled for 11:30am, right when everyone was either wanting to go to lunch, or for people not taking lunch probably the most productive middle part of the day. For those who went to lunch afterward, they never got to start before 12:30pm, and were out to at least 1…
So it wasn't scrum. It was just bullshitters using the word and doing what they wanted to do anyhow.
There may be a mythical "scrum" out there somewhere, but I and no one I've ever known has seen it. As much as I love a No True Scotsman fallacy, if this is the only thing people have ever seen and have ever attached the label "scrum" to...