8 ms·

I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the developmen

I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how. According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour. That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another. If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop! Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact. I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.

idts 8y ago
You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?
- DanielBMarkham 8y ago
  Talking about team communication in the abstract is difficult. I wrote a book about it. [1] The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing. If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value. On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible. 1. https://leanpub.com/info-ops https://leanpub.com/info-ops
  - Benjammer 8y ago
    Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?
    - DanielBMarkham 8y ago
      Ping me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients) You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here. There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up. No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.
deleted 8y ago
[deleted]
rm_-rf_slash 8y ago
The only useful result of standups that I ever saw consistently was when people spoke up about tasks they were blocked on, and cross-team collaboration allowed a pathway towards a solution to be established more quickly and smoothly than if the exchange had occurred over email or Slack. Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.
smileysteve 8y ago
I famously got outraged at my team the day after our planning meetings + interviews the whole team was on. "Yesterday we had meetings" because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.
- deleted 8y ago
  [deleted]
- s73v3r_ 8y ago
  But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the whole time talking about their thing, and a shyer person might not be able to get in a word that they otherwise really would have wanted/needed to.)
  - deleted 8y ago
    [deleted]
deanCommie 8y ago
"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.
- grimjack00 8y ago
  That is how I view it: - "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops. - "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother. I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
  - bunderbunder 8y ago
    I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management. As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever. That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
    - bogle 8y ago
      I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
    - GVIrish 8y ago
aunty_helen 8y ago
>Because they show common misunderstandings about Agile I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told. I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me) >If you can self-organize, effectively communicate, and help one another as-needed without standups Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended. Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.
- DanielBMarkham 8y ago
  I'm Old Expert Programmer Dude now, so I get to tell stories. 1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?" Another coach said nope, we're professionals! What do we need standups for? The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not. 2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around. He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball. I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster" He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away. I smiled as he left and asked him "Wasn't that a great standup!" "Nope. Could've had that conversation just the same without the stupid meeting" Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened. So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)
deleted 8y ago
[deleted]
s73v3r_ 8y ago
I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.
- splittingTimes 8y ago
  > they have no agency to change anything If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental. With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best. > due to the business people who are really in charge not wanting to change. Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
  - s73v3r_ 8y ago
    "If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental." I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies. "With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best." Again, not all the issues are ones that the Team directly can address. "Stand-ups should be only for the team and SM." Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.
ravitation 8y ago
Yes! This is right on the money. So many people forget that "being Agile" is an active undertaking, something that takes reflection and iterative improvement of not just the things you're building, but also the process you're using (in search of a way that works specifically for you and your team). One easy step is rethinking the classic standup questions, in a way to address the overall question "what do you need?".
colinprince 8y ago
Let the developers alone. This means the tech lead must find something else to do. Good. However, all the tech leads I've met think their job is to get up in my hair. Stop doing it, is what I want to say. However, we need to show the tech leads what we really need from them. So they don't displace their activity getting up in my hair.
tejaswiy 8y ago
That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument? Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer: "What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?" These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically. I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.
- dragonwriter 8y ago
  > These questions are effectively a way lay out a very clear path for management to basically micro-manage developers Well, they would if there was manager in the daily scrum. Which is why there isn't. (Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
  - barrkel 8y ago
    If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items. They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down. As a developer, this interaction feels a lot like micro-management.
KZeillmann 8y ago
It's so true. So many people think "Agile is bad because my company does ineffective standups". That's not what Agile is! Agile is about continuous improvement. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership
ulkesh 8y ago
In my experience, at least at bigger companies, standups are there to justify the project manager’s job. It’s for them to tally that everyone is doing their work. Simply, they see that the team wishes to meet for development purposes and it gets co-opted into a status meeting. I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.
- fyfy18 8y ago
  Feel free to send them this way. I’m currently working at a startup where the CEO is the product owner/manager, as well as doing all the CEO duties. A good PM would be a dream come true right now.
  - ulkesh 8y ago
    PMs have a role, no doubt. They should help facilitate discussion and help protect the team and communicate upward, and provide guidance where necessary. I have worked with some that did this well. I have also worked with some who cared so much about status that it negatively affected the team because they wanted five or more meetings a week (even stand-ups took an hour each). This type of disruption isn't limited to PMs, of course, it's just something I've found in my experience -- more-so than any other role.
virgilp 8y ago
You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to murderous regimes, maybe it's better to avoid it than to attempt to "implement it right, this time"? Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).
- citation_please 8y ago
  This seems like some application of "no true scottsman" combined with complex human interactions in a theoretically "simple" system. I guess the perfectly rational consumer fits in somehow too.
eeeeeeeeeeeee 8y ago
Can you articulate an example of a good versus a bad standup? Because your response is pretty vague. I've been on a lot of teams, read a lot about Agile and SCRUM, and just about every single one communicates stand-ups as a status update, not what you are indicating at all. If this was an isolated thing, I would agree with you, but when almost everyone is doing it this "wrong" way, as you say, I think the problem is with "agile," as loaded as that term is these days. I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.

idts 8y ago

You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?

DanielBMarkham 8y ago
Talking about team communication in the abstract is difficult. I wrote a book about it. [1] The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing. If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value. On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible. 1. https://leanpub.com/info-ops https://leanpub.com/info-ops
- Benjammer 8y ago
  Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?
  - DanielBMarkham 8y ago
    Ping me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients) You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here. There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up. No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.

deleted 8y ago

[deleted]

rm_-rf_slash 8y ago

The only useful result of standups that I ever saw consistently was when people spoke up about tasks they were blocked on, and cross-team collaboration allowed a pathway towards a solution to be established more quickly and smoothly than if the exchange had occurred over email or Slack. Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.

smileysteve 8y ago

I famously got outraged at my team the day after our planning meetings + interviews the whole team was on. "Yesterday we had meetings" because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.

deleted 8y ago
[deleted]
s73v3r_ 8y ago
But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the whole time talking about their thing, and a shyer person might not be able to get in a word that they otherwise really would have wanted/needed to.)
- deleted 8y ago
  [deleted]

deanCommie 8y ago

"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.

grimjack00 8y ago
That is how I view it: - "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops. - "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother. I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
- bunderbunder 8y ago
  I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management. As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever. That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
  - bogle 8y ago
    I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
  - GVIrish 8y ago

aunty_helen 8y ago

>Because they show common misunderstandings about Agile I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told. I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me) >If you can self-organize, effectively communicate, and help one another as-needed without standups Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended. Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.

DanielBMarkham 8y ago
I'm Old Expert Programmer Dude now, so I get to tell stories. 1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?" Another coach said nope, we're professionals! What do we need standups for? The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not. 2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around. He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball. I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster" He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away. I smiled as he left and asked him "Wasn't that a great standup!" "Nope. Could've had that conversation just the same without the stupid meeting" Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened. So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)

deleted 8y ago

[deleted]

s73v3r_ 8y ago

I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.

splittingTimes 8y ago
> they have no agency to change anything If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental. With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best. > due to the business people who are really in charge not wanting to change. Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
- s73v3r_ 8y ago
  "If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental." I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies. "With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best." Again, not all the issues are ones that the Team directly can address. "Stand-ups should be only for the team and SM." Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.

ravitation 8y ago

Yes! This is right on the money. So many people forget that "being Agile" is an active undertaking, something that takes reflection and iterative improvement of not just the things you're building, but also the process you're using (in search of a way that works specifically for you and your team). One easy step is rethinking the classic standup questions, in a way to address the overall question "what do you need?".

colinprince 8y ago

Let the developers alone. This means the tech lead must find something else to do. Good. However, all the tech leads I've met think their job is to get up in my hair. Stop doing it, is what I want to say. However, we need to show the tech leads what we really need from them. So they don't displace their activity getting up in my hair.

tejaswiy 8y ago

That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument? Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer: "What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?" These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically. I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.

dragonwriter 8y ago
> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers Well, they would if there was manager in the daily scrum. Which is why there isn't. (Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
- barrkel 8y ago
  If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items. They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down. As a developer, this interaction feels a lot like micro-management.

KZeillmann 8y ago

It's so true. So many people think "Agile is bad because my company does ineffective standups". That's not what Agile is! Agile is about continuous improvement. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership

ulkesh 8y ago

In my experience, at least at bigger companies, standups are there to justify the project manager’s job. It’s for them to tally that everyone is doing their work. Simply, they see that the team wishes to meet for development purposes and it gets co-opted into a status meeting. I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.

fyfy18 8y ago
Feel free to send them this way. I’m currently working at a startup where the CEO is the product owner/manager, as well as doing all the CEO duties. A good PM would be a dream come true right now.
- ulkesh 8y ago
  PMs have a role, no doubt. They should help facilitate discussion and help protect the team and communicate upward, and provide guidance where necessary. I have worked with some that did this well. I have also worked with some who cared so much about status that it negatively affected the team because they wanted five or more meetings a week (even stand-ups took an hour each). This type of disruption isn't limited to PMs, of course, it's just something I've found in my experience -- more-so than any other role.

virgilp 8y ago

You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to murderous regimes, maybe it's better to avoid it than to attempt to "implement it right, this time"? Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).

citation_please 8y ago
This seems like some application of "no true scottsman" combined with complex human interactions in a theoretically "simple" system. I guess the perfectly rational consumer fits in somehow too.

eeeeeeeeeeeee 8y ago

Can you articulate an example of a good versus a bad standup? Because your response is pretty vague. I've been on a lot of teams, read a lot about Agile and SCRUM, and just about every single one communicates stand-ups as a status update, not what you are indicating at all. If this was an isolated thing, I would agree with you, but when almost everyone is doing it this "wrong" way, as you say, I think the problem is with "agile," as loaded as that term is these days. I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.