What you said was "In daily Scrum meeting only the team and the Scrum Master are allowed by definition."
Which is fairly unequivocal. "By definition" the Scrum is open to observation by any actors outside the time.
Also, in many settings it is not "the team's right" since management and product owner sponsor the process.
Nevertheless in any sensible interpretation of Scrum only the bits that are relevant should be retained. My main issue of the wording is that these things are often taken up literally, even if only at the start. The sole purpose of the daily standup should be to facilitate open and candid communication between team members - it should specifically "not" be a show-and-tell for the the rest of the business.
Sounds good. I don't think it really matters the size of the organisation, though it does seem to be the bigger ones that are pushing it more. Perhaps the problems it seeks to solve are artefacts of organisational malaise where people just aren't as engaged or communicating any more. Yes Scrum is hugely time & effort intensive, and that is a fact that you must be aware of before having a go at it, and if "shit just gets done" well enough as it is you'd be best of staying clear. In dysfunctional organisations blamestorming happens anyway, but at least this way the playing-field is levelled.
Except that Waterfall isn't really a process at all. It's an antipattern that emerges when you take a laissez faire approach to the fulfilment of your development activities. If you check the wikipedia article: https://en.wikipedia.org/wiki/...
"Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice."
What Scrum "is" (or was) was an attempt to actively describe, or codify, the kind of things that effective teams do anyway.
Scrum is a good starting point and provides at the very least a suite of "exercises" which you can use to develop team and business collaboration. It can't compensate for poor technical leadership, though it might make such a deficiency more apparent.
Not quite. In daily Scrum meetings only the team and the Scrum Master are allowed *to participate*. Product owners, non-team business stakeholders, or anybody else for that matter are permitted but they have to stay quiet. Nevertheless I believe that the mere "presence" of these actors can have a negative effect on the quality of discussion...
Agreed. My experience is that most developers are rushed and overworked on SCRUM, which is exactly the opposite. What really pisses me off about it is that the very people who push SCRUM don't use it.
Yes, it is a common misconception that full Scrum is somehow a lightweight process. It's not, and it demands a lot of engagement from developers and business stakeholders. It usually fails when one or other of these groups doesn't participate, as it should/would, given any kind of sloppy process implementation.
My experience of Scrum is that while it doesn't in and of itself make your life easier, or produce better quality software, or help heal any organisational pathologies you may have, it does at least give you some certainty and predictability, and any operational, quality, or organisational issues that may have been heretofor papered over do become better understood.
"Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen"
Official Scrum says the stand-up is open to all, but only team members can actively participate - this is a mistake in my humble opinion. In my experience the presence of a senior figure can have a "chilling effect" on the quality of discussion.
As somebody who has employed scrum rigorously, and "in anger", in an industrial setting, I can only share my experiences. I don't know why "what you think I think" is suddenly the focus of this discussion, but I can certainly tell you that I am not one of your "many people" that believes it should be applied rote. So take your paradigm and stick it up your arse.
Absolutely, and this is something that Scrum can't really address - though I've seen a number of attempts. Scrum works best as a set of exercises to help people that are usually in a room together to collaborate. It fails when geography or scale are put into the mix.
That's great for you, as an individual. But as a team you're going to have to compromise as you become as strong as your weakest links. You need to address the overheads of communication and collaboration somehow and Scrum is a good way to start. It's not the end in itself - the communication and collaboration that comes about is - but it is a means to get there.
That's a good place to start, and it's a good approach to resolving the problem technically. Scrum seeks to address the social issues of project collaboration. If you understand your problem domain well enough that you can confidently write that unit-test and your colleagues too, and that the other players outside the team have confidence in your ability to do that, then you're right you have no need for Scrum.
One principle of the daily standup that I always objected to was that they should be "open to all"; that a senior business stakeholder for instance could walk in and "observe" the deliberations (she's not allowed to participate). But to me this undermines the openness and candidness of the discussion. What Glen Greenwald terms a "chilling effect" not unlike somebody coming over to your desk and watching you code over your shoulder. I think that two goals of the standup (1) to improve communication and develop relationships amongst the team and (2) to give any outsiders to the team an insight into deliberations are inherently contradictory.
I don't believe that Scrum is something that should be applied rote, it really is all about taking the bits that work for you. If a team doesn't need a forum for deliberating over vague, shifting requirements then they don't need stories and refinement. If they don't have issues with business stakeholder engagement then they don't need a formalised product owner role. If things run smoothly as they are then there's no need for a scrum master. Your team perhaps saw the benefit of more frequent structured discussion so they held on to the standup - but others might see this as an intrusion upon daily routine.
When taken as a whole scrum is intended to solve a whole plethora of operational and business issues around software development. It's good to try the whole lot out for a while to see what works for you but it certainly isn't something that should be forced if it doesn't feel like a good fit.
I had to laugh at your terming the various meetings as "ceremonies"; I would have called them "rituals" or "pageantry". These are typically things one participates in without fully understanding the meaning or purpose but you just follow tradition and through the performance one attains the knowledge. I wish I could remember the sociology terms the process by which one attempts to understand a culture by engaging in their rituals, to get a perspective from the inside.
But anyway, I digress point is, if you gave it a go, and it mostly didn't work, but you kept the bits that did then it sounds like you "did scrum".
Sorry, but I think you are speaking from your own experience there rather than from any wider perspective on the industry. I am glad that you have a tight established enterprise. I really am, but it's not reflective of the trends in the industry as a whole.
Slashdot Mirror
Hermeneutics https://en.wikipedia.org/wiki/...
Wow, you are a sad, sad man.
What you said was "In daily Scrum meeting only the team and the Scrum Master are allowed by definition."
Which is fairly unequivocal. "By definition" the Scrum is open to observation by any actors outside the time.
Also, in many settings it is not "the team's right" since management and product owner sponsor the process.
Nevertheless in any sensible interpretation of Scrum only the bits that are relevant should be retained. My main issue of the wording is that these things are often taken up literally, even if only at the start. The sole purpose of the daily standup should be to facilitate open and candid communication between team members - it should specifically "not" be a show-and-tell for the the rest of the business.
It's an oldie but a goodie (-:
no, really, you're a super guy. you've convinced me.
Sounds good. I don't think it really matters the size of the organisation, though it does seem to be the bigger ones that are pushing it more. Perhaps the problems it seeks to solve are artefacts of organisational malaise where people just aren't as engaged or communicating any more. Yes Scrum is hugely time & effort intensive, and that is a fact that you must be aware of before having a go at it, and if "shit just gets done" well enough as it is you'd be best of staying clear. In dysfunctional organisations blamestorming happens anyway, but at least this way the playing-field is levelled.
Yes but in my case it's a medically prescribed suppository.
Except that Waterfall isn't really a process at all. It's an antipattern that emerges when you take a laissez faire approach to the fulfilment of your development activities. If you check the wikipedia article: https://en.wikipedia.org/wiki/...
"Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice."
What Scrum "is" (or was) was an attempt to actively describe, or codify, the kind of things that effective teams do anyway.
Scrum is a good starting point and provides at the very least a suite of "exercises" which you can use to develop team and business collaboration. It can't compensate for poor technical leadership, though it might make such a deficiency more apparent.
Not quite. In daily Scrum meetings only the team and the Scrum Master are allowed *to participate*. Product owners, non-team business stakeholders, or anybody else for that matter are permitted but they have to stay quiet. Nevertheless I believe that the mere "presence" of these actors can have a negative effect on the quality of discussion ...
https://www.mountaingoatsoftwa...
Agreed. My experience is that most developers are rushed and overworked on SCRUM, which is exactly the opposite. What really pisses me off about it is that the very people who push SCRUM don't use it.
Yes, it is a common misconception that full Scrum is somehow a lightweight process. It's not, and it demands a lot of engagement from developers and business stakeholders. It usually fails when one or other of these groups doesn't participate, as it should/would, given any kind of sloppy process implementation.
My experience of Scrum is that while it doesn't in and of itself make your life easier, or produce better quality software, or help heal any organisational pathologies you may have, it does at least give you some certainty and predictability, and any operational, quality, or organisational issues that may have been heretofor papered over do become better understood.
When you choose all three you can't say with any certainty which you'll actually get when all is said and done - if indeed you get any of them at all.
https://www.mountaingoatsoftwa...
"Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen"
Official Scrum says the stand-up is open to all, but only team members can actively participate - this is a mistake in my humble opinion. In my experience the presence of a senior figure can have a "chilling effect" on the quality of discussion.
I'd rather that too than have to listen to you filling the discussion with warm air.
As somebody who has employed scrum rigorously, and "in anger", in an industrial setting, I can only share my experiences. I don't know why "what you think I think" is suddenly the focus of this discussion, but I can certainly tell you that I am not one of your "many people" that believes it should be applied rote. So take your paradigm and stick it up your arse.
Absolutely, and this is something that Scrum can't really address - though I've seen a number of attempts. Scrum works best as a set of exercises to help people that are usually in a room together to collaborate. It fails when geography or scale are put into the mix.
Except for where you expect each of these big things should be shippable in their own right yeah not so easy now
That's it exactly. I don't know why you were modded down. If I could mod you up I would.
That's great for you, as an individual. But as a team you're going to have to compromise as you become as strong as your weakest links. You need to address the overheads of communication and collaboration somehow and Scrum is a good way to start. It's not the end in itself - the communication and collaboration that comes about is - but it is a means to get there.
That's a good place to start, and it's a good approach to resolving the problem technically. Scrum seeks to address the social issues of project collaboration. If you understand your problem domain well enough that you can confidently write that unit-test and your colleagues too, and that the other players outside the team have confidence in your ability to do that, then you're right you have no need for Scrum.
Well aren't you great.
It's not "bullshit" because you have a contrary definition. You say PM, I say potato.
One principle of the daily standup that I always objected to was that they should be "open to all"; that a senior business stakeholder for instance could walk in and "observe" the deliberations (she's not allowed to participate). But to me this undermines the openness and candidness of the discussion. What Glen Greenwald terms a "chilling effect" not unlike somebody coming over to your desk and watching you code over your shoulder. I think that two goals of the standup (1) to improve communication and develop relationships amongst the team and (2) to give any outsiders to the team an insight into deliberations are inherently contradictory.
To me this sounds like "doing it right"
I don't believe that Scrum is something that should be applied rote, it really is all about taking the bits that work for you. If a team doesn't need a forum for deliberating over vague, shifting requirements then they don't need stories and refinement. If they don't have issues with business stakeholder engagement then they don't need a formalised product owner role. If things run smoothly as they are then there's no need for a scrum master. Your team perhaps saw the benefit of more frequent structured discussion so they held on to the standup - but others might see this as an intrusion upon daily routine.
When taken as a whole scrum is intended to solve a whole plethora of operational and business issues around software development. It's good to try the whole lot out for a while to see what works for you but it certainly isn't something that should be forced if it doesn't feel like a good fit.
I had to laugh at your terming the various meetings as "ceremonies"; I would have called them "rituals" or "pageantry". These are typically things one participates in without fully understanding the meaning or purpose but you just follow tradition and through the performance one attains the knowledge. I wish I could remember the sociology terms the process by which one attempts to understand a culture by engaging in their rituals, to get a perspective from the inside.
But anyway, I digress point is, if you gave it a go, and it mostly didn't work, but you kept the bits that did then it sounds like you "did scrum".
Sorry, but I think you are speaking from your own experience there rather than from any wider perspective on the industry. I am glad that you have a tight established enterprise. I really am, but it's not reflective of the trends in the industry as a whole.