5 ms·

I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto: > Individuals and in

by flukus 10y ago

I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto: > Individuals and interactions over processes and tools Probably breaking the fourth too: > Responding to change over following a plan How many companies have done a retrospective on whether the daily recitation of Kanban board movements is providing any value?

jwdunne 10y ago
To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in and overhauls your processes. That is, in effect, processes and tools straight up, from the minute that scrum master goes on a course. It wouldn't be much of a course if it didn't teach some process for implementing SCRUM. It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is really bothering them and how you can deliver working software quickly to alleviate that. So you have daily standup a, weekly retrospectives, a designated master, product owner, a process for estimation, a n-week sprint. Those are must haves. That's all process.
- Underqualified 10y ago
  One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before. I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings. Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.
  - dasmoth 10y ago
    Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1]. Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive. [1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...
    - Underqualified 10y ago
      Micromanagement is indeed what it looked like to me with all the daily stand ups (what did you do yesterday), review meetings (what did you do last week ?), scoring (what do you mean it would take you longer than that other developer to finish something ?) and sprints (we HAVE to do this THIS WEEK).
      - jwdunne 10y ago
        That's certainly what it can be used for and probably is on a large scale. The most important one that a lot seem to miss is the "did you face any road blocks?", with a culture where the whole team thinks and removes the roadblock such that it is removed for everybody for good. Morphine is a pretty damn good painkiller. Unfortunately, it is extremely easy to abuse to the point where there are more people abuse it than people who genuinely benefit from it. On a larger scale, communism as it was originally conceived sounds like a utopia. Unfortunately, the only thing that's actually happened is an abuse that takes anything from democracy to authoritarian regimes well towards totalitarianism, the anti-thesis of communism. Scrum and agile is the same in that respect. Sounds great. Works well on paper but very rarely used correctly or with the original intention.
    - maxxxxx 10y ago
      That's what turned me away from Scrum. When you do something really difficult you end up reporting the same thing for weeks. Or you feel you shouldn't even try something difficult because you can't break down into little daily chunks. I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.
    - overgard 10y ago
      That blog post is really odd. It's like "sure you're being micromanaged, but its by a mob instead of a tyrant", as though thats a comforting thing. How is that better?! You cant just throw the word "team" in there and pretend it makes things ok.
- mikekchar 10y ago
  I think you have the same misconception about the first rule that many people do (forgive me if I'm wrong). > Individuals and interactions over processes and tools This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try to encourage interactions through as many avenues as you can. You don't say, "You must use this tool and only this tool to communicate". But it's a mistake to think that you want to remove process. That's not "agile". That's "ad hoc". There is nothing particularly wrong with ad hoc processes if you are successful, but the "we'll just use common sense" approach that many teams attempt is usually anything but successful. Process is there to support individuals. When I am coaching a team, I never go in with the idea of introducing any particular process. Of course, I am more skilled with some processes than others, but imposing my skill on a team I am coaching is not going to be successful. Instead, I watch what people are doing and write it down. That is the process. At that point I start looking at problems that we can solve. I look for places where the process is not consistent, or where people are struggling because they don't know what to do. Then I try to extend the existing processes so that it is consistent across the team. Finally, I start introducing things that I'm skillful in where I am sure it will make a difference. At this point the team is already delivering with their process and we are just looking at ways to optimise. There is a lot more to it that this, of course. However, for me this is the minimum thing that you need to do to coach a team. I've tried other approaches (when forced to by upper management), but I've never been successful.
  - flukus 10y ago
    > But it's a mistake to think that you want to remove process. It's also a mistake to keep a process that isn't delivering any benefit though. I've seen very few stand-ups that provided a benefit and zero where there was no other way to get the same benefit.
    - LoSboccacc 10y ago
      especially as the team and code grow there's little reason for standups, nobody cares about what most of the other people tells anyway unless they're effected in their goals. much better to have a team leader who knows the tasks for everyone and warn people when they are operating an area where they can step on each other toes, so that they know they need to coordinate. the Nx(N-1) rigid reporting structure of stand up makes very little sense
Swizec 10y ago
> I'd argue stand up meetings are the opposite of agile Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience. Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ...
- flukus 10y ago
  > Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience. For me it's almost always a waste of 15 minutes. I get to hear 8 people mention what they're up to even though only 1 or 2 (on a good day) will be having any impact on what I'm working on. Of those 2 it's generally more effective to send an email or update the issue so I don't forget about it 5 minutes later.
- douche 10y ago
  > Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ... Amen. Especially when the only proper response is a LMGTFY.
PJDK 10y ago
We've talked about the stand up a few times in retros. We've mixed it up a few times (we now do a task based stand up rather than a person based one) but always felt it was more valuable than not having it.
deleted 10y ago
[deleted]

by flukus 10y ago

jwdunne 10y ago

To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in and overhauls your processes. That is, in effect, processes and tools straight up, from the minute that scrum master goes on a course. It wouldn't be much of a course if it didn't teach some process for implementing SCRUM. It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is really bothering them and how you can deliver working software quickly to alleviate that. So you have daily standup a, weekly retrospectives, a designated master, product owner, a process for estimation, a n-week sprint. Those are must haves. That's all process.

Underqualified 10y ago
One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before. I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings. Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.
- dasmoth 10y ago
  Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1]. Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive. [1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...
  - Underqualified 10y ago
    Micromanagement is indeed what it looked like to me with all the daily stand ups (what did you do yesterday), review meetings (what did you do last week ?), scoring (what do you mean it would take you longer than that other developer to finish something ?) and sprints (we HAVE to do this THIS WEEK).
    - jwdunne 10y ago
      That's certainly what it can be used for and probably is on a large scale. The most important one that a lot seem to miss is the "did you face any road blocks?", with a culture where the whole team thinks and removes the roadblock such that it is removed for everybody for good. Morphine is a pretty damn good painkiller. Unfortunately, it is extremely easy to abuse to the point where there are more people abuse it than people who genuinely benefit from it. On a larger scale, communism as it was originally conceived sounds like a utopia. Unfortunately, the only thing that's actually happened is an abuse that takes anything from democracy to authoritarian regimes well towards totalitarianism, the anti-thesis of communism. Scrum and agile is the same in that respect. Sounds great. Works well on paper but very rarely used correctly or with the original intention.
  - maxxxxx 10y ago
    That's what turned me away from Scrum. When you do something really difficult you end up reporting the same thing for weeks. Or you feel you shouldn't even try something difficult because you can't break down into little daily chunks. I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.
  - overgard 10y ago
    That blog post is really odd. It's like "sure you're being micromanaged, but its by a mob instead of a tyrant", as though thats a comforting thing. How is that better?! You cant just throw the word "team" in there and pretend it makes things ok.
mikekchar 10y ago
I think you have the same misconception about the first rule that many people do (forgive me if I'm wrong). > Individuals and interactions over processes and tools This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try to encourage interactions through as many avenues as you can. You don't say, "You must use this tool and only this tool to communicate". But it's a mistake to think that you want to remove process. That's not "agile". That's "ad hoc". There is nothing particularly wrong with ad hoc processes if you are successful, but the "we'll just use common sense" approach that many teams attempt is usually anything but successful. Process is there to support individuals. When I am coaching a team, I never go in with the idea of introducing any particular process. Of course, I am more skilled with some processes than others, but imposing my skill on a team I am coaching is not going to be successful. Instead, I watch what people are doing and write it down. That is the process. At that point I start looking at problems that we can solve. I look for places where the process is not consistent, or where people are struggling because they don't know what to do. Then I try to extend the existing processes so that it is consistent across the team. Finally, I start introducing things that I'm skillful in where I am sure it will make a difference. At this point the team is already delivering with their process and we are just looking at ways to optimise. There is a lot more to it that this, of course. However, for me this is the minimum thing that you need to do to coach a team. I've tried other approaches (when forced to by upper management), but I've never been successful.
- flukus 10y ago
  > But it's a mistake to think that you want to remove process. It's also a mistake to keep a process that isn't delivering any benefit though. I've seen very few stand-ups that provided a benefit and zero where there was no other way to get the same benefit.
  - LoSboccacc 10y ago
    especially as the team and code grow there's little reason for standups, nobody cares about what most of the other people tells anyway unless they're effected in their goals. much better to have a team leader who knows the tasks for everyone and warn people when they are operating an area where they can step on each other toes, so that they know they need to coordinate. the Nx(N-1) rigid reporting structure of stand up makes very little sense

Swizec 10y ago

> I'd argue stand up meetings are the opposite of agile Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience. Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ...

flukus 10y ago
> Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience. For me it's almost always a waste of 15 minutes. I get to hear 8 people mention what they're up to even though only 1 or 2 (on a good day) will be having any impact on what I'm working on. Of those 2 it's generally more effective to send an email or update the issue so I don't forget about it 5 minutes later.
douche 10y ago
> Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ... Amen. Especially when the only proper response is a LMGTFY.

PJDK 10y ago

We've talked about the stand up a few times in retros. We've mixed it up a few times (we now do a task based stand up rather than a person based one) but always felt it was more valuable than not having it.

deleted 10y ago

[deleted]