5 ms·

The whole point of Agile was "people not processes" However because at my company we have professional scrum masters, everything must be religiously Agile. Thi

The whole point of Agile was "people not processes" However because at my company we have professional scrum masters, everything must be religiously Agile. This means that we must have a standup, everyday. we must have a retro, we must have planning. almost half a day a week is lost to pointless meetings. I just want to get on with my job. Trust me to use the ticketing system to figure out what I'm doing and raising blocking issues.

davidgerard 10y ago
The free E-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though. sprint: artificial crisis end of sprint: abandonware Scrum Master: CV credit for my planned escape to a new company stakeholder: someone you can't get away with externalising your costs onto, because they can hammer a wooden spike through your heart Project Manager: a job that no longer needs to exist in the astounding new world of Scrum! (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.) simplified: doesn't implement the actual business requirements lightweight: doesn't implement the actual business requirements, but does so much more elegantly than the version that works easy: project was born circling the drain (and doesn't implement the actual business requirements) legacy: the version that works and implements the actual business requirements, though no sane human wants to touch it user story: a valiant attempt to extract coherent requirements and bug reports; ends up being precise specifications for the wing feathers of the desired magical flying unicorn pony velocity: a speed with a direction: skittering about following marketing's random hairpin turns retrospective: blamestorm incoming! stand-up: establishing blamestorm targets early Inspect and Adapt: perhaps bong hits will fix my makefile We'll put that on the backlog: ahaha fuck you doing Agile wrong: noticing any of the above. I do enjoy some of the jargon. empowered: do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that." Every good idea is turned into a bad one by the relentless management quest to Taylorise clue. (originally posted by me at https://reddragdiva.dreamwidth.org/594955.html https://reddragdiva.dreamwidth.org/594955.html )
- ebiester 10y ago
  I'd say that if any of that is happening, then yes, you're doing agile wrong. :) Most importantly, a product where that happens is missing a definition of done. Done includes, among other things, automated tests, good code quality, and a product owner looking at it and saying, "yes, this will actually meet the business requirements." If it doesn't get done within the 2 weeks, then it rolls over to the next two weeks. If not enough shit gets done in a 2 week sprint (and yes, I hate sprint as a concept), then you schedule less work. That two weeks are efforts to work in small chunks (something good developers do anyway) and give a general sense of when the project will be done. That means that everyone is aware earlier that a project's scope or timeline is unrealistic. You're doing this rewrite because shit is slow to change; it's the developers' fucking job to point out that repeating the same problem again is a waste of money. (Agile means pointing out unicorn fantasies as early as possible as to make the hard decisions before the project is 3 months late.) Now, personally, I prefer continuous flow boards and cycle time to measure that. Then, you can skip the sprint bullshit, but that's a detail. Finally, the problem you describe is a rewrite. If the problem is that nobody wants to touch that code with a ten foot pole, then you are "fucking empowered" to spend that same time to clean that shit up. Unless business requirements have changed and the software is no longer the right thing to do (see: implements the actual business requirements) then the right, sane thing to do is get a copy of Michael Feathers' Working With Legacy Code and dig in. Using an agile methodology to do a dumb thing doesn't make it any more or less dumb.
  - davidgerard 10y ago
    As I said: "Every good idea is turned into a bad one by the relentless management quest to Taylorise clue."
InclinedPlane 10y ago
When I was at (unnamed-giant-online-retailer) we had a big project for a while that resulted in having standups that had about a dozen people in them and lasted about 45 minutes to an hour typically. Every day. My mind still boggles how nobody else questioned such a misuse of resources.
- qihqi 10y ago
  I was at (unnamed-giant-online-retailer) and a team of 12 too. Our rule is to speak with one foot standing so you have to speak fast... It takes 90 seconds per person usually, sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards". Same process run by different group will feel different.
  - Udik 10y ago
    Oh really? And, tell me, do you agree to speak with your foot standing for 90 seconds? What about, I don't know, with someone pinching you or kicking your arse? Would that further reduce the time? Seriously - if I need to talk, I do, for as long as I think it's necessary. If I don't need to talk, and I don't need to hear other people's updates, this is just, how can I put it? Humiliating.
    - deleted 10y ago
      [deleted]
  - turar 10y ago
    What about jumping up and down while giving your update? That could literally become an Amazon version of "how high" meme.
  - Udik 10y ago
    > sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards" Which means, given a 8 hours working day, that you've been needing the help of Dave since the previous day, for an average of 4 hours, and you didn't ask him yet?
zzalpha 10y ago
This means that we must have a standup, everyday. we must have a retro, we must have planning. Every single one of those ritutuals has value. Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is. I have yet to see an agile shop that doesn't benefit from stand-up to keep the team coordinated and on track. And retros are the forum for self-management and process refinement/iteration. Moreover, some of those rituals (like sprint planning) are also needed by stakeholders other than the developers themselves in order to get their jobs done. Because, believe it or not, coders are not in fact the center of the universe. almost half a day a week is lost to pointless meetings. I just want to get on with my job. Woah, wait, wut? 90% of your time is apparently spent coding and that's a problem for you? You know, at some point this starts to sound a lot like an excessive sense of entitlement...
- jjnoakes 10y ago
  > Every single one of those rituals has value. Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is. The reverse is also true. Just because a daily standup has value for some doesn't mean it has value for everyone.
- KaiserPro 10y ago
  Nice, jump to the asperger stereotype. Every single one of those rituals has value. For you/your company. why? because Agile is empiric. Every company is different. The whole point of Agile, is to be nimble, and respond to evidence. I know what my customer wants, because I talk to them. Funnily enough I like my customers. I want to know how they are using my services. I like talking to people because I am human. Because my stakeholders are different to my customers, I have to actively fight "Agile" to get my job done. I have to do the TCO calcs, I have to fight for my resources. The feedback loop is looping on the wrong part. But because the agile book says its ok, it must not be changed. But its ok "People not process". I have once been in a company where agile was done "right". It was refined to the point where we had one meeting a week(effectively a retro). Feedback was done through jira, which provides rich metrics. Collaboration was expected to happen as and when it was needed. If you couldn't figure it out, then you were in the wrong job. you needed to be able to talk human. Why is that agile? because the process was mapped to the company, and tweaked until it produced measurable results. Not the other way round. Everywhere else it feels like agile is a religion that must be observed, never questioned. Woe betide anyone that dares question the knowledge of the vicar as they mumble the softly spoken spells during stand up.
eldavido 10y ago
I think you're onto something here. I like to refer to them as "little-a" agile (iterative delivery, accept change, basically the original manifesto) and "big-A" agile: scrum masters, stand-ups, all that. Devs have to act like adult professionals though, and keep their issues updated, otherwise they deserve the long, boring meetings they so loathe :)

davidgerard 10y ago

The free E-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though. sprint: artificial crisis end of sprint: abandonware Scrum Master: CV credit for my planned escape to a new company stakeholder: someone you can't get away with externalising your costs onto, because they can hammer a wooden spike through your heart Project Manager: a job that no longer needs to exist in the astounding new world of Scrum! (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.) simplified: doesn't implement the actual business requirements lightweight: doesn't implement the actual business requirements, but does so much more elegantly than the version that works easy: project was born circling the drain (and doesn't implement the actual business requirements) legacy: the version that works and implements the actual business requirements, though no sane human wants to touch it user story: a valiant attempt to extract coherent requirements and bug reports; ends up being precise specifications for the wing feathers of the desired magical flying unicorn pony velocity: a speed with a direction: skittering about following marketing's random hairpin turns retrospective: blamestorm incoming! stand-up: establishing blamestorm targets early Inspect and Adapt: perhaps bong hits will fix my makefile We'll put that on the backlog: ahaha fuck you doing Agile wrong: noticing any of the above. I do enjoy some of the jargon. empowered: do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that." Every good idea is turned into a bad one by the relentless management quest to Taylorise clue. (originally posted by me at https://reddragdiva.dreamwidth.org/594955.html https://reddragdiva.dreamwidth.org/594955.html )

ebiester 10y ago
I'd say that if any of that is happening, then yes, you're doing agile wrong. :) Most importantly, a product where that happens is missing a definition of done. Done includes, among other things, automated tests, good code quality, and a product owner looking at it and saying, "yes, this will actually meet the business requirements." If it doesn't get done within the 2 weeks, then it rolls over to the next two weeks. If not enough shit gets done in a 2 week sprint (and yes, I hate sprint as a concept), then you schedule less work. That two weeks are efforts to work in small chunks (something good developers do anyway) and give a general sense of when the project will be done. That means that everyone is aware earlier that a project's scope or timeline is unrealistic. You're doing this rewrite because shit is slow to change; it's the developers' fucking job to point out that repeating the same problem again is a waste of money. (Agile means pointing out unicorn fantasies as early as possible as to make the hard decisions before the project is 3 months late.) Now, personally, I prefer continuous flow boards and cycle time to measure that. Then, you can skip the sprint bullshit, but that's a detail. Finally, the problem you describe is a rewrite. If the problem is that nobody wants to touch that code with a ten foot pole, then you are "fucking empowered" to spend that same time to clean that shit up. Unless business requirements have changed and the software is no longer the right thing to do (see: implements the actual business requirements) then the right, sane thing to do is get a copy of Michael Feathers' Working With Legacy Code and dig in. Using an agile methodology to do a dumb thing doesn't make it any more or less dumb.
- davidgerard 10y ago
  As I said: "Every good idea is turned into a bad one by the relentless management quest to Taylorise clue."

InclinedPlane 10y ago

When I was at (unnamed-giant-online-retailer) we had a big project for a while that resulted in having standups that had about a dozen people in them and lasted about 45 minutes to an hour typically. Every day. My mind still boggles how nobody else questioned such a misuse of resources.

qihqi 10y ago
I was at (unnamed-giant-online-retailer) and a team of 12 too. Our rule is to speak with one foot standing so you have to speak fast... It takes 90 seconds per person usually, sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards". Same process run by different group will feel different.
- Udik 10y ago
  Oh really? And, tell me, do you agree to speak with your foot standing for 90 seconds? What about, I don't know, with someone pinching you or kicking your arse? Would that further reduce the time? Seriously - if I need to talk, I do, for as long as I think it's necessary. If I don't need to talk, and I don't need to hear other people's updates, this is just, how can I put it? Humiliating.
  - deleted 10y ago
    [deleted]
- turar 10y ago
  What about jumping up and down while giving your update? That could literally become an Amazon version of "how high" meme.
- Udik 10y ago
  > sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards" Which means, given a 8 hours working day, that you've been needing the help of Dave since the previous day, for an average of 4 hours, and you didn't ask him yet?

zzalpha 10y ago

This means that we must have a standup, everyday. we must have a retro, we must have planning. Every single one of those ritutuals has value. Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is. I have yet to see an agile shop that doesn't benefit from stand-up to keep the team coordinated and on track. And retros are the forum for self-management and process refinement/iteration. Moreover, some of those rituals (like sprint planning) are also needed by stakeholders other than the developers themselves in order to get their jobs done. Because, believe it or not, coders are not in fact the center of the universe. almost half a day a week is lost to pointless meetings. I just want to get on with my job. Woah, wait, wut? 90% of your time is apparently spent coding and that's a problem for you? You know, at some point this starts to sound a lot like an excessive sense of entitlement...

jjnoakes 10y ago
> Every single one of those rituals has value. Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is. The reverse is also true. Just because a daily standup has value for some doesn't mean it has value for everyone.
KaiserPro 10y ago
Nice, jump to the asperger stereotype. Every single one of those rituals has value. For you/your company. why? because Agile is empiric. Every company is different. The whole point of Agile, is to be nimble, and respond to evidence. I know what my customer wants, because I talk to them. Funnily enough I like my customers. I want to know how they are using my services. I like talking to people because I am human. Because my stakeholders are different to my customers, I have to actively fight "Agile" to get my job done. I have to do the TCO calcs, I have to fight for my resources. The feedback loop is looping on the wrong part. But because the agile book says its ok, it must not be changed. But its ok "People not process". I have once been in a company where agile was done "right". It was refined to the point where we had one meeting a week(effectively a retro). Feedback was done through jira, which provides rich metrics. Collaboration was expected to happen as and when it was needed. If you couldn't figure it out, then you were in the wrong job. you needed to be able to talk human. Why is that agile? because the process was mapped to the company, and tweaked until it produced measurable results. Not the other way round. Everywhere else it feels like agile is a religion that must be observed, never questioned. Woe betide anyone that dares question the knowledge of the vicar as they mumble the softly spoken spells during stand up.

eldavido 10y ago

I think you're onto something here. I like to refer to them as "little-a" agile (iterative delivery, accept change, basically the original manifesto) and "big-A" agile: scrum masters, stand-ups, all that. Devs have to act like adult professionals though, and keep their issues updated, otherwise they deserve the long, boring meetings they so loathe :)