15 ms·

I think you need to separate Agile from Scrum to be honest. Agile is at is core just some suggestions for teams to work well together. There are no stand ups o

I think you need to separate Agile from Scrum to be honest. Agile is at is core just some suggestions for teams to work well together. There are no stand ups or sprints or whatever. Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). There is an interview/article by one of the creators of the agile manifesto (Kent Beck maybe?, will try to dig it up and edit the answer if I find -> was Robert C. Martin, see below) where he explains a bit the story and compares it to Agile (and basically says scrum has nothing to do with the original agile manifesto) On a personal level, I hate scrum. The stand ups, the sprints, the retros or grooming or whatever they have nowadays. It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it. It may work for others, but for me personally, I hate it with a fervour. Though I agree with the Agile manifesto though, unfortunately it isn't very 'manager' friendly so you usually get scrum instead. Edit: link to a reference to the article, can't find the original but found this: https://www.aaron-gray.com/a-criticism-of-scrum/#scrum-strains-the-relationship-between-management-and-developers https://www.aaron-gray.com/a-criticism-of-scrum/#scrum-strai...

Graffur 6y ago
I don't have much interview experience so I am wondering how you do this: "It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it" Do you abruptly cut the interview short or do you just make a mental note and continue?
- The_Amp_Walrus 6y ago
  Typically you would just make a mental note and continue. Walking out mid interview is considered kind of rude and it's worthwhile in the long run to not be rude if you can avoid it.
- uxp100 6y ago
  I'm not the person you're responding to, but just make a mental note and continue. Personally I'd even continue the interview process, I'm a Scrum hater, but an interesting project, a smart team, a big paycheck? You might have to put up with scrum, it's widespread.
- odshoifsdhfs 6y ago
  I don't get up and leave. Usually in most interviews at the end companies ask if you have any questions. I usually try to understand their processes and ways of working. Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I had a few replies thanking me, most just don't reply and I had one (only one) insulting me and my experience and saying they only interviewed me out of pity as my experience wasn't good enough (I had more years (8) of experience in the tech stack they used than the number of years the company existed!:)) Was from a Who's Hiring thread here actually :)
  - bitwize 6y ago
    > Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I LOVE sending letters like this. It's the politest middle finger you can give to a douchey hiring manager or organization.
    - scudd 6y ago
      I think the value of calming down is normally to not send impolite or passive aggressive communications. I don't have so much experience interacting with recruiters/hiring managers. However, every time I've let some frustration show at work, in the moment I felt vindicated and righteous, only to feel like an ass about 24 hours later. Normally when I feel the need to vocalize a frustration, I try to write down or remember why I'm frustrated, but wait to actually action the communication until I'm calm. Goes a long way to focus on solving problems, without identifying people as the problem.
nix-zarathustra 6y ago
>Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry. [0] https://en.wikipedia.org/wiki/Scrum_(software_development)#History https://en.wikipedia.org/wiki/Scrum_(software_development)#H...
- odshoifsdhfs 6y ago
  Thank you for the info. I will leave the comment as is for reference. Again, thank you!
- klingon79 6y ago
  Japanese also came up with Kaizen, which Scrum should be about but isn’t, along with Kanban, the process- not the generic term for workflow that some use it as. While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
  - Guthur 6y ago
    XP for me is the core of agile software engineering I can relate to, principle driven rather than process focused a'la Scrum. For me scrum optimises for a very narrow perspective of software development which did not align well with long term and sustainable software engineering and ownership. If i was far less than generous I'd say scrum is design for children rather than responsible adults. For success as a leader i should be focusing on building and fostering a team than does not need the self imposed constraints of scrum but are rather conscientious and vested enough to build and deliver what the company needs and the team can maintain.
    - stephenhuey 6y ago
      Scrum is pretty lightweight. A lot of people add to the core of Scrum and refer to the whole thing as Scrum when that is not accurate. A few uber coders in a garage cranking out their dream idea may not need Scrum. In my experience, it’s most needed in the corporate world where there are tons of development teams being hounded by managers and product owners to constantly cram more and more work into a fixed amount of time left before some arbitrary deadline, and getting management buy-in on Scrum or something similar can actually be a much-needed protection for dev team sanity.
tootie 6y ago
I personally wouldn't work at a place that didn't do it. Scrum ceremonies are there to get alignment. If you don't do them, you end up working on the wrong things. If these meetings take up more than 1-2 hours a week, then you're doing it wrong.
- odshoifsdhfs 6y ago
  If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a problem with scrum itself. No true Scotsman and all that. I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.
  - stephenhuey 6y ago
    I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing. If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
    - chris11 6y ago
      > people using Waterfall for software development. Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman. > but not usually for software where you learn more from users about what should be done and tweaked as you go along I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.
campers 6y ago
I've found the retrospectives to be the most valuable part of the scrum ceremonies, taking the time to talk through what could be improved etc. Stand-ups tend to be too much of a status report to the manager and are more valuable when its the developers talking between themselves and sharing knowledge of their work. My biggest dislike for Scrum is how managers can use it to turn "agile" into basically a MS Project plan from the estimates.
- systemvoltage 6y ago
  > are more valuable when its the developers talking between themselves and sharing knowledge of their work This is the biggest lie of standups. No one gives a shit about standups. Everyone is waiting for their turn and then not listening to others. Let's stop pretending. If they need help, they'll reach out to the expert on 1:1 basis. Way more productive, way more concise, better bonds, privacy and learning experience. No one waits until standup and be like "Gee.. I should ask this help in front of 8 others and waste everyone's time".
  - lmm 6y ago
    This is completely false for the majority of places I've worked. Plenty of people don't notice how much they've got stuck, or don't know who the right expert is, or feel self-conscious about interrupting them to ask a question. Having a daily scheduled time where all the experts are available and everyone should check whether they're getting bogged down is a big help. I've experienced the kind of "standup" you describe too, but it usually coincided with not actually following the rules for what a standup is (e.g. not actually standing up) and a bunch of other fake agile.
    - systemvoltage 6y ago
      Huh? How are people not contacting the experts or reaching out for help? Seems fundamental to being a professional, doesn’t matter what profession. That seems like a bad culture more than anything else.
haolez 6y ago
Spot on. Bringing the stakeholder to the squad (just for a daily meeting, for example) is a great Agile insight which doesn't need Scrum at all. I highly recommend it.
leguy 6y ago
Are you totally anti process? If not, which process do you find more palatable than scrum? Your comment is eye opening for me because I don’t know that I’d find a job if I decided scrum was a dealbreaker. What kind of projects or companies do you target that don’t have some flavor of scrum? I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.
- aprdm 6y ago
  If you’re looking for a book — shape up — from basecamp goes through how they develop software and it looks great ! I am giving it a try. It’s very agile but not scrum. I also agree that after a team gels together there’s no need for a lot of the overhead that comes with scrum. My experience in organizations have always been to continuously shape the process depending on how the team feels about it and not call it scrum
  - ukd1 6y ago
    We've been using this since late 2019, and generally been loving it. The concept of things being bets, plus fixed-time variable-scope are amazing, imho.
  - wilmoore 6y ago
    I've interviewed with a couple teams that are using Shape Up and I got the general sense that the developers were happy with the process. Here is the readable on the web version: https://basecamp.com/shapeup/webbook https://basecamp.com/shapeup/webbook Obligatory PDF: https://basecamp.com/shapeup/shape-up.pdf https://basecamp.com/shapeup/shape-up.pdf Shape Up Your Agile (article): https://thinkfractional.blog/shape-up-your-agile/ https://thinkfractional.blog/shape-up-your-agile/
- muzani 6y ago
  I've never had an issue communicating with a team without scrum, even when very new. On the other hand, communication gets worse with scrum, in my experience. Because everyone knows that the meetings are the time to communicate problems, they often delay all communication until the next day. And in some cases the morning meetings drag out to noon because that's when all the communication is going on, when it really just involves 2-3 people.
a3n 6y ago
When the manifesto came out I thought it was a great idea, as I recall. But now I can't recall what was in it. Something about "people, not popcorn." Or was that The Cathedral and the Bazaar? You can say we should separate agile from scrum, but scrum basically is agile today (and Kanban!), modulo the odd free thinking, practically self-managed shop. Agile comes in via consultant after a shop declares itself on a "burning platform." What it's become, IMO, is work about work. I hated it. The only contact I have with it now is when my manager has to hang up the phone because she has to go to the standup of other managers. (I drive a truck.)
- blabitty 6y ago
  The infamous scrum of scrums. Always makes me laugh. I think all status meetings should be abolished, without exception. Meetings should be for making a decision with all the players present.
  - lanstin 6y ago
    Or requirements writing sprints. How agile, how aware of the limitations of big up front design.
  - saberdancer 6y ago
    Scrums and such meetings are for the benefit of the organizer (boss, ...). Only exception is if someone is blocked but he is bad at expressing it directly to the person responsible. I've been part of many meetings/scrums where the point was that the manager gets the info of how things are progressing but the meeting itself was net negative for the developers as they lost their flow and some of their time.
deleted 6y ago
[deleted]
uberswe 6y ago
In my experience, the teams that do scrum well don’t do scrum by the book. They look at scrum and modify the things they like to work for them and get rid of things they don’t like.
- hvidgaard 6y ago
  Which is one of the core principles of Scrum. Scrum as taught it merely the starting point.
felipellrocha 6y ago
> but for me personally, I hate it with a fervour Is it possible to fall in love with someone so quickly over one line written on the web?
- herodoturtle 6y ago
  Agile indeed.
- odshoifsdhfs 6y ago
  I am taken but thank you for the laugh :)
ako 6y ago
Agile/scrum is not about software development. It's about business agility, managing uncertainty, and being able to adopt what you're doing to new information and new market situations. You can't design, review and test new product designs in a word document. You need to be able to iterate, learn, adopt. PDCA: Plan, Do, Check, Act. Scrum is just a framework that implements this. Main benefit for the business is that you don't have long periods where you can't change where you're going. And if you change your mind, you don't want to have to throw away a lot of useless investment. So you only plan short sprints, you deliver quickly, generate ROI, and improve your plan where you're heading. Just a way to manage uncertainty.
refurb 6y ago
In terms of stand ups and such, it really depends on how well they are done. Typically, they just become another box to check. “This task is underway, blah, blah..” and everyone tunes out. I’ve seen them done well and usually because they are focused on prioritization - “is this still important? No? Stop doing it”.
ohthehugemanate 6y ago
Er... the scrum specific ceremonies are supposed to be a starting point for a team. The point of retros is to adapt your process to the team's needs as you go. So if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting. Scrum and all agile processes are owned by the development team (including the PO). If they're imposing a cost and not bringing value to the developers, you're supposed to change them.
- pracer 6y ago
  > If they're imposing a cost and not bringing value to the developers, you're supposed to change them. And then, based on the comments seeing here, you are doing it wrong because >if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.
danjac 6y ago
Scrum is basically warmed-up Taylorism[1] for the 21st century, couched in buzzwords like "sprints" and "retros". It's an attempt to make software development an industrial process, stripping developers of autonomy and creativity in return for predictability. Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!"), because they like to be "data-driven". [1] https://en.wikipedia.org/wiki/Scientific_management https://en.wikipedia.org/wiki/Scientific_management
- BlargMcLarg 6y ago
  The irony is that one could still have predictability and metrics without Scrum, and they would likely say as much if not more. Instead of expecting your devs to manually participate in rituals, you can use their actual output over a large time frame and extrapolate those. Admittedly, that is my biggest problem with Scrum. Humans are by default the most volatile factor. While we could minimize its contribution, Scrum instead inflates the importance of the human factor. Example: estimating. Grooming the back log for priority with just the people who are critical in deciding that priority, is common sense. Almost every methodology recommends this. Yet estimating is a tough sell: at the start, it is largely deemed useless due to inexperience. Yet as experience in estimating furthers, so too do metrics become available which make estimating unnecessary. Worse is when estimating and even re-estimating practices can easily eat entire days worth of productivity (a few hours per person + a high likelihood of hours around that meeting to be less efficient than could-be, loss or lack of flow). This is before we add that estimating has very little empirical evidence behind it (#NoEstimates) and psychological effects make things even more volatile (anchoring effect, Parkinson's Law, etc.) I can't speak for others, but I went into this field because I want to minimize the human factor in anything mundane or boring, allowing people to maximize their participation in anything fun and exciting. For me, Scrum does the exact opposite.
  - nialv7 6y ago
    > The irony is that one could still have predictability and metrics without Scrum I like to think that it would take a technically competent manager to understand the progress and performance of the developers. OTOH, with Scrum, you can generate numbers, however meaningless, without such prerequisites. That's probably why some managers like it.
nialv7 6y ago
> Scrum was created by one of the creators of the agile manifesto I can't wrap my head around this. The first item of the agile manifesto literally says: Individuals and interactions over processes and tools
- odshoifsdhfs 6y ago
  From the link > When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine… > Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.
rkangel 6y ago
> Agile is at is core just some suggestions for teams to work well together I don't think that's right. Agile is a way to manage projects as an alternative to waterfall. The 'communication' stuff on top of that might work well with it, but that's all to do with how you run your agile process. Agile itself is just about the order you do stuff. Imagine that for your project, there 3 'features' that are needed. Each feature needs, designing, implementing and validating (testing it works). You end up with this grid of all the work that needs doing: F1 F2 F3 Desi Impl Vali In waterfall, you progress through this grid top to bottom. You design all the features, then you implement all the features and then you validate all the features. In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then you move on to feature 2, then feature 3. The reasons for doing this are many and varied. The obvious ones being that in waterfall you don't have anything useful until everything is done, whereas in Agile at least you have F1 fully done a third of the way through. This also means that you can decide that F3 is more important than F2, and then later that F4 which you'd never heard of is needed when F2 isn't (and you can decide this as you go along). This bare concept of agile is almost always what you want to do, particularly for software projects. The concepts of backlogs, sprints etc. are all the process that has built up to make this work in real life. Approaches such as Scrum have then built on top of that giving a whole lot of extra practices about how teams should work. A lot of that is variable in usefulness and how well it is used. You don't want to get away from the underlying value of the agile process though.

Graffur 6y ago

I don't have much interview experience so I am wondering how you do this: "It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it" Do you abruptly cut the interview short or do you just make a mental note and continue?

The_Amp_Walrus 6y ago
Typically you would just make a mental note and continue. Walking out mid interview is considered kind of rude and it's worthwhile in the long run to not be rude if you can avoid it.
uxp100 6y ago
I'm not the person you're responding to, but just make a mental note and continue. Personally I'd even continue the interview process, I'm a Scrum hater, but an interesting project, a smart team, a big paycheck? You might have to put up with scrum, it's widespread.
odshoifsdhfs 6y ago
I don't get up and leave. Usually in most interviews at the end companies ask if you have any questions. I usually try to understand their processes and ways of working. Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I had a few replies thanking me, most just don't reply and I had one (only one) insulting me and my experience and saying they only interviewed me out of pity as my experience wasn't good enough (I had more years (8) of experience in the tech stack they used than the number of years the company existed!:)) Was from a Who's Hiring thread here actually :)
- bitwize 6y ago
  > Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I LOVE sending letters like this. It's the politest middle finger you can give to a douchey hiring manager or organization.
  - scudd 6y ago
    I think the value of calming down is normally to not send impolite or passive aggressive communications. I don't have so much experience interacting with recruiters/hiring managers. However, every time I've let some frustration show at work, in the moment I felt vindicated and righteous, only to feel like an ass about 24 hours later. Normally when I feel the need to vocalize a frustration, I try to write down or remember why I'm frustrated, but wait to actually action the communication until I'm calm. Goes a long way to focus on solving problems, without identifying people as the problem.

nix-zarathustra 6y ago

>Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry. [0] https://en.wikipedia.org/wiki/Scrum_(software_development)#History https://en.wikipedia.org/wiki/Scrum_(software_development)#H...

odshoifsdhfs 6y ago
Thank you for the info. I will leave the comment as is for reference. Again, thank you!
klingon79 6y ago
Japanese also came up with Kaizen, which Scrum should be about but isn’t, along with Kanban, the process- not the generic term for workflow that some use it as. While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
- Guthur 6y ago
  XP for me is the core of agile software engineering I can relate to, principle driven rather than process focused a'la Scrum. For me scrum optimises for a very narrow perspective of software development which did not align well with long term and sustainable software engineering and ownership. If i was far less than generous I'd say scrum is design for children rather than responsible adults. For success as a leader i should be focusing on building and fostering a team than does not need the self imposed constraints of scrum but are rather conscientious and vested enough to build and deliver what the company needs and the team can maintain.
  - stephenhuey 6y ago
    Scrum is pretty lightweight. A lot of people add to the core of Scrum and refer to the whole thing as Scrum when that is not accurate. A few uber coders in a garage cranking out their dream idea may not need Scrum. In my experience, it’s most needed in the corporate world where there are tons of development teams being hounded by managers and product owners to constantly cram more and more work into a fixed amount of time left before some arbitrary deadline, and getting management buy-in on Scrum or something similar can actually be a much-needed protection for dev team sanity.

tootie 6y ago

I personally wouldn't work at a place that didn't do it. Scrum ceremonies are there to get alignment. If you don't do them, you end up working on the wrong things. If these meetings take up more than 1-2 hours a week, then you're doing it wrong.

odshoifsdhfs 6y ago
If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a problem with scrum itself. No true Scotsman and all that. I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.
- stephenhuey 6y ago
  I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing. If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
  - chris11 6y ago
    > people using Waterfall for software development. Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman. > but not usually for software where you learn more from users about what should be done and tweaked as you go along I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.

campers 6y ago

I've found the retrospectives to be the most valuable part of the scrum ceremonies, taking the time to talk through what could be improved etc. Stand-ups tend to be too much of a status report to the manager and are more valuable when its the developers talking between themselves and sharing knowledge of their work. My biggest dislike for Scrum is how managers can use it to turn "agile" into basically a MS Project plan from the estimates.

systemvoltage 6y ago
> are more valuable when its the developers talking between themselves and sharing knowledge of their work This is the biggest lie of standups. No one gives a shit about standups. Everyone is waiting for their turn and then not listening to others. Let's stop pretending. If they need help, they'll reach out to the expert on 1:1 basis. Way more productive, way more concise, better bonds, privacy and learning experience. No one waits until standup and be like "Gee.. I should ask this help in front of 8 others and waste everyone's time".
- lmm 6y ago
  This is completely false for the majority of places I've worked. Plenty of people don't notice how much they've got stuck, or don't know who the right expert is, or feel self-conscious about interrupting them to ask a question. Having a daily scheduled time where all the experts are available and everyone should check whether they're getting bogged down is a big help. I've experienced the kind of "standup" you describe too, but it usually coincided with not actually following the rules for what a standup is (e.g. not actually standing up) and a bunch of other fake agile.
  - systemvoltage 6y ago
    Huh? How are people not contacting the experts or reaching out for help? Seems fundamental to being a professional, doesn’t matter what profession. That seems like a bad culture more than anything else.

haolez 6y ago

Spot on. Bringing the stakeholder to the squad (just for a daily meeting, for example) is a great Agile insight which doesn't need Scrum at all. I highly recommend it.

leguy 6y ago

Are you totally anti process? If not, which process do you find more palatable than scrum? Your comment is eye opening for me because I don’t know that I’d find a job if I decided scrum was a dealbreaker. What kind of projects or companies do you target that don’t have some flavor of scrum? I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.

aprdm 6y ago
If you’re looking for a book — shape up — from basecamp goes through how they develop software and it looks great ! I am giving it a try. It’s very agile but not scrum. I also agree that after a team gels together there’s no need for a lot of the overhead that comes with scrum. My experience in organizations have always been to continuously shape the process depending on how the team feels about it and not call it scrum
- ukd1 6y ago
  We've been using this since late 2019, and generally been loving it. The concept of things being bets, plus fixed-time variable-scope are amazing, imho.
- wilmoore 6y ago
  I've interviewed with a couple teams that are using Shape Up and I got the general sense that the developers were happy with the process. Here is the readable on the web version: https://basecamp.com/shapeup/webbook https://basecamp.com/shapeup/webbook Obligatory PDF: https://basecamp.com/shapeup/shape-up.pdf https://basecamp.com/shapeup/shape-up.pdf Shape Up Your Agile (article): https://thinkfractional.blog/shape-up-your-agile/ https://thinkfractional.blog/shape-up-your-agile/
muzani 6y ago
I've never had an issue communicating with a team without scrum, even when very new. On the other hand, communication gets worse with scrum, in my experience. Because everyone knows that the meetings are the time to communicate problems, they often delay all communication until the next day. And in some cases the morning meetings drag out to noon because that's when all the communication is going on, when it really just involves 2-3 people.

a3n 6y ago

When the manifesto came out I thought it was a great idea, as I recall. But now I can't recall what was in it. Something about "people, not popcorn." Or was that The Cathedral and the Bazaar? You can say we should separate agile from scrum, but scrum basically is agile today (and Kanban!), modulo the odd free thinking, practically self-managed shop. Agile comes in via consultant after a shop declares itself on a "burning platform." What it's become, IMO, is work about work. I hated it. The only contact I have with it now is when my manager has to hang up the phone because she has to go to the standup of other managers. (I drive a truck.)

blabitty 6y ago
The infamous scrum of scrums. Always makes me laugh. I think all status meetings should be abolished, without exception. Meetings should be for making a decision with all the players present.
- lanstin 6y ago
  Or requirements writing sprints. How agile, how aware of the limitations of big up front design.
- saberdancer 6y ago
  Scrums and such meetings are for the benefit of the organizer (boss, ...). Only exception is if someone is blocked but he is bad at expressing it directly to the person responsible. I've been part of many meetings/scrums where the point was that the manager gets the info of how things are progressing but the meeting itself was net negative for the developers as they lost their flow and some of their time.

deleted 6y ago

[deleted]

uberswe 6y ago

In my experience, the teams that do scrum well don’t do scrum by the book. They look at scrum and modify the things they like to work for them and get rid of things they don’t like.

hvidgaard 6y ago
Which is one of the core principles of Scrum. Scrum as taught it merely the starting point.

felipellrocha 6y ago

> but for me personally, I hate it with a fervour Is it possible to fall in love with someone so quickly over one line written on the web?

herodoturtle 6y ago
Agile indeed.
odshoifsdhfs 6y ago
I am taken but thank you for the laugh :)

ako 6y ago

Agile/scrum is not about software development. It's about business agility, managing uncertainty, and being able to adopt what you're doing to new information and new market situations. You can't design, review and test new product designs in a word document. You need to be able to iterate, learn, adopt. PDCA: Plan, Do, Check, Act. Scrum is just a framework that implements this. Main benefit for the business is that you don't have long periods where you can't change where you're going. And if you change your mind, you don't want to have to throw away a lot of useless investment. So you only plan short sprints, you deliver quickly, generate ROI, and improve your plan where you're heading. Just a way to manage uncertainty.

refurb 6y ago

In terms of stand ups and such, it really depends on how well they are done. Typically, they just become another box to check. “This task is underway, blah, blah..” and everyone tunes out. I’ve seen them done well and usually because they are focused on prioritization - “is this still important? No? Stop doing it”.

ohthehugemanate 6y ago

Er... the scrum specific ceremonies are supposed to be a starting point for a team. The point of retros is to adapt your process to the team's needs as you go. So if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting. Scrum and all agile processes are owned by the development team (including the PO). If they're imposing a cost and not bringing value to the developers, you're supposed to change them.

pracer 6y ago
> If they're imposing a cost and not bringing value to the developers, you're supposed to change them. And then, based on the comments seeing here, you are doing it wrong because >if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.

danjac 6y ago

Scrum is basically warmed-up Taylorism[1] for the 21st century, couched in buzzwords like "sprints" and "retros". It's an attempt to make software development an industrial process, stripping developers of autonomy and creativity in return for predictability. Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!"), because they like to be "data-driven". [1] https://en.wikipedia.org/wiki/Scientific_management https://en.wikipedia.org/wiki/Scientific_management

BlargMcLarg 6y ago
The irony is that one could still have predictability and metrics without Scrum, and they would likely say as much if not more. Instead of expecting your devs to manually participate in rituals, you can use their actual output over a large time frame and extrapolate those. Admittedly, that is my biggest problem with Scrum. Humans are by default the most volatile factor. While we could minimize its contribution, Scrum instead inflates the importance of the human factor. Example: estimating. Grooming the back log for priority with just the people who are critical in deciding that priority, is common sense. Almost every methodology recommends this. Yet estimating is a tough sell: at the start, it is largely deemed useless due to inexperience. Yet as experience in estimating furthers, so too do metrics become available which make estimating unnecessary. Worse is when estimating and even re-estimating practices can easily eat entire days worth of productivity (a few hours per person + a high likelihood of hours around that meeting to be less efficient than could-be, loss or lack of flow). This is before we add that estimating has very little empirical evidence behind it (#NoEstimates) and psychological effects make things even more volatile (anchoring effect, Parkinson's Law, etc.) I can't speak for others, but I went into this field because I want to minimize the human factor in anything mundane or boring, allowing people to maximize their participation in anything fun and exciting. For me, Scrum does the exact opposite.
- nialv7 6y ago
  > The irony is that one could still have predictability and metrics without Scrum I like to think that it would take a technically competent manager to understand the progress and performance of the developers. OTOH, with Scrum, you can generate numbers, however meaningless, without such prerequisites. That's probably why some managers like it.

nialv7 6y ago

> Scrum was created by one of the creators of the agile manifesto I can't wrap my head around this. The first item of the agile manifesto literally says: Individuals and interactions over processes and tools

odshoifsdhfs 6y ago
From the link > When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine… > Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.

rkangel 6y ago

> Agile is at is core just some suggestions for teams to work well together I don't think that's right. Agile is a way to manage projects as an alternative to waterfall. The 'communication' stuff on top of that might work well with it, but that's all to do with how you run your agile process. Agile itself is just about the order you do stuff. Imagine that for your project, there 3 'features' that are needed. Each feature needs, designing, implementing and validating (testing it works). You end up with this grid of all the work that needs doing: F1 F2 F3 Desi Impl Vali In waterfall, you progress through this grid top to bottom. You design all the features, then you implement all the features and then you validate all the features. In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then you move on to feature 2, then feature 3. The reasons for doing this are many and varied. The obvious ones being that in waterfall you don't have anything useful until everything is done, whereas in Agile at least you have F1 fully done a third of the way through. This also means that you can decide that F3 is more important than F2, and then later that F4 which you'd never heard of is needed when F2 isn't (and you can decide this as you go along). This bare concept of agile is almost always what you want to do, particularly for software projects. The concepts of backlogs, sprints etc. are all the process that has built up to make this work in real life. Approaches such as Scrum have then built on top of that giving a whole lot of extra practices about how teams should work. A lot of that is variable in usefulness and how well it is used. You don't want to get away from the underlying value of the agile process though.