5 ms·

I've never felt like a stand-up with your manager-type-person present is ever net helpful. Stand-ups just implicitly become "what did you do yesterday that just

I've never felt like a stand-up with your manager-type-person present is ever net helpful. Stand-ups just implicitly become "what did you do yesterday that justified 10% of your biweekly paycheck" at some level, and people end up talking to the manager rather than to each other. I'm sure some super special orgs out there can counteract this with their incredible non-toxic culture and such. Most cannot. Ones that explicitly think they can almost certainly actually cannot. If it's solely the IC's, I think that's where it can be good. People feel a lot more free to not say anything if they don't have any blockers and don't need to put anything to the team. It's much easier to get in-and-out and have a high-bandwidth discussion. I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. And we had an open-door policy (not literally/physically of course) if you ever needed to discuss blockers or put things to the team. "Standups" happened naturally, about once or twice as week, where people would accrete into a standup in the middle of our pod discussing something that was so interesting/relevant that it naturally drew us out of our offices. Maybe that was just the only time where we finally had the team and the process mesh on a natural level, and it doesn't prescribe this as "the way to do it" for anyone else. But damn did it work for us, for at least two years, before the org changed enough that our team didn't really exist as the same team anymore. One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". That and everything related to it was awful.

908B64B197 6y ago
Agile/Scrum is great if done properly. Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work. Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.
- myth2018 6y ago
  > Agile/Scrum is great if done properly. and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects. Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time. Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures. It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition. But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings. I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
  - 908B64B197 6y ago
    > Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
    - myth2018 6y ago
      How so? You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)? In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation. I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
matwood 6y ago
A good team can make any process work, just like a bad manager/team can destroy the best process. I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management). I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up. I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed. Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.
- user5994461 6y ago
  >>> I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I'm curious how bigs were your teams? and if you were all local in the same office? There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.
  - matwood 6y ago
    10 or less people, mixed in office and remote. Mine have almost always been fairly informal, and early on (I'm in my 40s) pre-agile it was just a what's up type thing. So while there was a scheduled time, it was a very free form meeting. We would talk a bit about work, last nights video game, etc... If people were already deep into some work, it was fine to miss.
path411 6y ago
Honestly I feel like a team that communicates healthily in channels on slack kinda defeats the entire purpose of stand ups. At my current job, we even have the customers for my team in slack channels and they are highly communicative, so honestly it makes the whole scrum model seem just a waste of time when I can start a question/thread right in slack with the product owners/customers
- sixstringtheory 6y ago
  We have a #daily-updates channel where we can just drop status and blockers. We roll it up into a weekly summary.
stephenhuey 6y ago
At my last full-time position in the corporate world we were doing Scrum well. The daily scrum was short and not for any manager - team members shared quick updates and blockers with each other. Before we had Scrum enforced, all the dev teams suffered from chaos caused by product owners constantly changing priorities mid-sprint or adding “just one more feature” several times during the sprint, so once the product owners agreed to stick to Scrum the team was able to enjoy some sanity in their work.
Viliam1234 6y ago
According to Scrum, the manager should not even be present during the daily stand-up. (More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.) > I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time". > One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".
closeparen 6y ago
I thought this way when I started working, but I'm grudgingly coming around. It's easiest to keep a house clean out of respect for the people you live with. It's easiest to consistently dress and groom well when you're meeting people whose opinions you value. It's easiest to stick to exercise when it's an appointment with other people. You will cook and eat best in social and family meals. A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.

908B64B197 6y ago

Agile/Scrum is great if done properly. Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work. Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.

myth2018 6y ago
> Agile/Scrum is great if done properly. and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects. Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time. Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures. It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition. But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings. I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
- 908B64B197 6y ago
  > Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
  - myth2018 6y ago
    How so? You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)? In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation. I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with

matwood 6y ago

A good team can make any process work, just like a bad manager/team can destroy the best process. I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management). I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up. I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed. Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.

user5994461 6y ago
>>> I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I'm curious how bigs were your teams? and if you were all local in the same office? There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.
- matwood 6y ago
  10 or less people, mixed in office and remote. Mine have almost always been fairly informal, and early on (I'm in my 40s) pre-agile it was just a what's up type thing. So while there was a scheduled time, it was a very free form meeting. We would talk a bit about work, last nights video game, etc... If people were already deep into some work, it was fine to miss.

path411 6y ago

Honestly I feel like a team that communicates healthily in channels on slack kinda defeats the entire purpose of stand ups. At my current job, we even have the customers for my team in slack channels and they are highly communicative, so honestly it makes the whole scrum model seem just a waste of time when I can start a question/thread right in slack with the product owners/customers

sixstringtheory 6y ago
We have a #daily-updates channel where we can just drop status and blockers. We roll it up into a weekly summary.

stephenhuey 6y ago

At my last full-time position in the corporate world we were doing Scrum well. The daily scrum was short and not for any manager - team members shared quick updates and blockers with each other. Before we had Scrum enforced, all the dev teams suffered from chaos caused by product owners constantly changing priorities mid-sprint or adding “just one more feature” several times during the sprint, so once the product owners agreed to stick to Scrum the team was able to enjoy some sanity in their work.

Viliam1234 6y ago

According to Scrum, the manager should not even be present during the daily stand-up. (More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.) > I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time". > One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".

closeparen 6y ago

I thought this way when I started working, but I'm grudgingly coming around. It's easiest to keep a house clean out of respect for the people you live with. It's easiest to consistently dress and groom well when you're meeting people whose opinions you value. It's easiest to stick to exercise when it's an appointment with other people. You will cook and eat best in social and family meals. A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.