12 ms·

> Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. Hmmm. I was just thinking the opposite yesterday. I'm a

> Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. Hmmm. I was just thinking the opposite yesterday. I'm a performance engineer working closely with two teams. One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. I find the non agile team more productive, efficient and dare I say happy. The Agile based team makes me sit in on their daily scrum meetings. Although every one uses it to sync up on their dependancies, it just drags for an hour almost every day. I can visibly tell the devs walking out of the room spend more time worrying about "velocity" and "organisation of work" than the money making work that needs to be done. It almost feels like the agile process gives them "one more job" of picking the doable things from the list of stuff that needs to be done so they look better than their peers with better velocity. Simply put, I was thinking if Agile is just not a good method when you can strive for good leadership and a healthy collaboration among individuals of the team?

PaulHoule 10y ago
Scrums and stand-up meetings are mostly a waste of time. Scheduling frequent milestones is not.
seren 10y ago
1 hour daily meeting sounds horrible (and dysfunctional) whatever the development life cycle looks like.
dcminter 10y ago
Assuming this is scrum or something similar then if "[the standup] just drags for an hour almost every day" then they're not really doing it right. I've been in well run Agile teams - and they're wonderful. I've been in badly run "Agile" teams and they're soul destroying. Either way agile is not the problem (or, I dare say, the solution).
- iainmerrick 10y ago
  One thing I've observed in (badly-run, I think) Agile teams is big standup meetings, where if anyone starts a discussion or even asks a question (rather than just reporting status) somebody immediately says "offline!" -- i.e., have that discussion after the meeting. I can see that the motivation is to avoid wasting the whole team's time on a discussion that only needs two or three people; but suppressing discussion can hurt too, as it stops people learning about tricky issues outside of their immediate work area. It would be helpful to have some rules of thumb to show when you're doing Agile wrong. Probably those exist already -- anyone got a good link? And probably "too many people in the standup meeting" is a good rule of thumb! Dragging on for an hour sounds absolutely awful. I'd even say more than about six people is too many.
  - AnimalMuppet 10y ago
    I've been in a situation where we did agile with 30 people. Standup took 10-15 minutes.
    - iainmerrick 10y ago
      Did it work well?
      - AnimalMuppet 10y ago
        Extremely. You'd take ten seconds to say what you had to say. Sometimes you'd say "I need help with SQL", say, and someone would say "I'll help", and you'd be done. But we had a real agile guru on the team. We didn't do "Agile Methodology" exactly; we did Extreme Programming, and we kept tweaking it. Sometimes he'd say "let's try changing our approach in this way for the next two iterations, and see how it works out". We'd do the experiment, and keep the changes or not. We kept hacking and experimenting with the process, in a controlled way, but never in a "this is how it's done" way. So if you have an "Agile is the one right way" person trying to run your team with big-A Agile, and he/she wants to do 30-person standups, you're probably in trouble...
        iainmerrick 10y ago
        Sounds great! Keeping track of how well the process itself is working, especially, and being willing to continually tweak it to fit the team and project.
  - nostrademons 10y ago
    The point of a standup is to learn that there is a tricky issue outside of your immediate work area, and to know who's got expertise on it. That way you know who to contact if "outside" becomes "inside". The actual details, you hash out in a separate meeting with just the people involved. "Offline!" is absolutely the right response if a standup starts veering into technical details. I had one team of 10 that had a problem with our standups extending into half an hour once. We resolved that we'd make the standup one minute shorter each day. After a month and a half, we had it down to a one-minute standup (6 seconds per person). It was still useful, though a bit extreme - I'd target about 5 minutes for a 10-person standup (30 seconds per).
WalterSear 10y ago
It doesn't sound like the 'Agile' team is doing standups right. There are either too many people in the room, or people are talking too much, and probably about the wrong things. And, if they are doing standups wrong, I question how much else they are cargo-culting.
- reacharavindh 10y ago
  Yes, everyone in there knows that scrum meetings should be short, but somehow those meetings take long, because everyone thinks their questions needs answers and their dependabcies definitely must be resolved.. so, an hour it goes.
  - WalterSear 10y ago
    The point of a standup isn't to get answers or resolve dependencies - it's to make others aware of them. The first thing we do after stand ups is have a bunch of quick one-on-one or small group meetings.
  - acbabis 10y ago
    Our meeting format was for each person to say a) What they worked on, b) What they were about to work on, and c) If they needed help with anything. Our rule was that you could ask for help as long as you were just scheduling a time to meet after the stand-up. It worked really, really well. Then we got a new scrum master whose desired format was to talk about each item on the Kanban board each day, even the ones that weren't being worked on.
    - lisivka 10y ago
      It's status meeting. Developers unlike status meeting, so they invented their own meeting: daily standup meeting.
  - blub 10y ago
    This is really bad and a major failure on the part of the scrum master. The point of this meeting is to help the team sync on what they are doing and what they plan to do. It should take 10m at most. Any issues (blockers, dependencies, etc) should be taken to separate ad-hoc discussions to let the team get back to work.
Davertron 10y ago
Is everything else between these two groups completely equal? I seriously doubt it is, in which case I don't think it's fair to make any conclusions that hold weight. This is one of the problems I have with these sorts of things. My company went Agile about two years ago, and lots of people like to rant about how much better everything is now and how much more productive we all are because of it. Except we actually have no way of knowing whether it made any difference at all.
- reacharavindh 10y ago
  Sorry, I should have made it clearer. I ranted likea personal thought than a definitive statement. The teams work on different projects. The diversity and experience of its members are different. They are not strictly comparable. But, looking at both teams from above, it feels like the non agile team is very simple and it works. The agile team is more complicated and works only on paper.
  - piva00 10y ago
    From my personal experience: experienced teams can thrive with almost no methodology and an ad-hoc process because... They had experience with other processes and can see the good and bad in them. I still advocate agile for less homogeneous teams or in situations like other posts have highlighted but a team of more senior developers with a working process that is open to be improved (one of the cornerstones of agile) will thrive with less churn than when forced into a by-the-book agile process.
    - meheleventyone 10y ago
      For me Agile is by definition an ad-hoc process just one with guiding principles for how to go about organising it. The problem comes with formalised methodologies based on Agile which are treated as a one size fits all approach for any team.
solipsism 10y ago
Seems like people think using Agile and using your brain is an either-or kind of thing. It's not magic.
UK-AL 10y ago
Scrum != Agile. Heck its sounds if your doing scrum wrong anyhow. Kanban board, prioritization, CI + CD, automated tests is probably about as much agile as most companies need.
iainmerrick 10y ago
One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. The ad-hoc approach also sounds quite agile (at least with a small 'a'). It's certainly closer to Agile than to Waterfall, assuming they didn't do a big design up front before writing any code. I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process.
- btilly 10y ago
  But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process. But of course. If you just cherry-pick and experiment, then you won't have any reason to pay an expensive expert to tell you how to do it right!
- strken 10y ago
  I'm not a huge fan of Scrum, but there's a grain of truth in there. If you're forced to use the whole thing, it's harder to creatively misinterpret the underlying spirit by e.g. having one hour "standups" where everyone is sitting down, having a backlog that covers a year of work in excruciating detail, or estimating in hours then using those estimates to fire people.
- squeaky-clean 10y ago
  > I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process. I'm a big Scrum fan (when it works), and my biggest takeaway is that it's exactly meant for cherry-picking and modifying. The best team I've ever been on was one where we were all using Scrum for the first time. We were constantly trying to mold it to fit us best, and it ended up looking nothing like the original model of Scrum. It was also the only time I've ever been on a Scrum team that did proper retrospectives, which I think is the biggest point! Pretty much every other team has either ignored it ("Why do we need to discuss Scrum, it's in the book and laid out for us.") or merged it with the Review, so that managers, stakeholders, and people outside the team are involved in that. And no one wants to suggest changes or raise complaints with outsiders watching. Too many people seem to read a book about Scrum, memorize all the concepts and rules and abide by it, without reading any of the justification behind it. If you swear we need story points, and they need to follow a fibonacci scale, but you can't tell me why story points are better than estimating hours, you're doing it wrong (and then points always get fucking conflated with hours anyways). If you understand that story points are just one way of estimating a task's effort relative to other tasks, and that relative estimates tend to be easier to make, and scale better with all the other estimates when things change, then you're allowed to make the call of whether story points are best for the team, or a different estimating system, or none at all. Even better than someone understanding that, everyone on the team should understand that and be able to weigh in.
mfrommil 10y ago
A "1 hour daily standup" is not agile. The point of a stand-up is just that... everyone can stand because the meeting is so short. Ideally 15 minutes max.
- iainmerrick 10y ago
  It's annoying when people get really dogmatic about having to stand up in the stand-up meeting. I know it's supposed to remind and encourage everyone to keep the meeting short, but in my experience that simply doesn't work.
  - dood 10y ago
    Agreed, enforcing standing up but not brevity is the worst way to do standups, and a clear sign of pure cargo-culting.
  - AnimalMuppet 10y ago
    Maybe not. But have a culture that the meeting really is that short, and let people sit if they want to.
    - iainmerrick 10y ago
      Agreed. Don't force people to stand, keep it so short and sweet so that people want to stand.
transitorykris 10y ago
Nowhere does Agile say you have to do standups or measure velocity :) At some point the team that's inventing its own process will find it stops working, what's important is if they can identify when that happens and find new ways of getting things done. http://agilemanifesto.org/ http://agilemanifesto.org/
vorpalhex 10y ago
Agile is a very loaded word. One meaning of Agile is a very specific kind of process, the other meaning and perhaps closer to the original manifesto is what you're describing with the "non-agile" team.
RandomOpinion 10y ago
> I can visibly tell the devs walking out of the room spend more time worrying about "velocity" and "organisation of work" than the money making work that needs to be done. It almost feels like the agile process gives them "one more job" of picking the doable things from the list of stuff that needs to be done so they look better than their peers with better velocity. Classic symptom of managers using agile as a (micro)management tool. Velocity, burndown charts, etc. are meant to be used by the team as a self-calibration tool. Managers do not get a say in what they think the velocity should be, either for the team or for individuals. If they do so, they create an incentive (let's be blunt, an overwhelming incentive) for the team/individuals to game them and that way lies madness. (As an aside, the best response I've ever seen to this type of dysfunction is a team who simply decided to retcon the charts on the fly to make the work committed to match the work done. Management was happy that the burndown chart was right on target, developers were free to be fully productive instead of worrying about what their velocity looked like; it was a win-win solution all around.)
- dcminter 10y ago
  I was once on a project where an "agile" team, at the behest of their managers, held a sprint "to improve velocity." I kid you not. I will add that I was not on that team. Our scrum master, who was excellent, shielded us entirely from the management madness.
  - ci5er 10y ago
    What was the idea behind this? Spending some dedicated time knocking through some accumulated crud? (I think people call it 'technical debt' these days). Is that a bad thing?
    - dcminter 10y ago
      Nope. That I could have respected and would have made some sense. It was code for "the team will work longer hours and over the weekend so that an arbitrary number is higher."
deleted 10y ago
[deleted]
jjuel 10y ago
The reason it is referred to as a stand up is because it is short and you stand up for the whole thing. An hour long meeting is just that an hour long meeting. Something is not working right in that agile situation which is why they aren't happy.
squeaky-clean 10y ago
Just because someone says they're using Agile doesn't actually mean it. Your non-agile team sounds much closer to the actual goals of "Agile".
user5994461 10y ago
Agile is not a method. It's just a buzzword.
sydd 10y ago
You are not doing agile. In a daily scrum you cannot have conversations, its just everyone stating 3 things: What I was working on yesterday, what I will do today, and whether I need help today from someone. For a team of 10 people (a large agile team!) it should not last for more than 15 mins. I guess other parts are broken too, if they dont even know how to do a standup.

PaulHoule 10y ago

Scrums and stand-up meetings are mostly a waste of time. Scheduling frequent milestones is not.

seren 10y ago

1 hour daily meeting sounds horrible (and dysfunctional) whatever the development life cycle looks like.

dcminter 10y ago

Assuming this is scrum or something similar then if "[the standup] just drags for an hour almost every day" then they're not really doing it right. I've been in well run Agile teams - and they're wonderful. I've been in badly run "Agile" teams and they're soul destroying. Either way agile is not the problem (or, I dare say, the solution).

iainmerrick 10y ago
One thing I've observed in (badly-run, I think) Agile teams is big standup meetings, where if anyone starts a discussion or even asks a question (rather than just reporting status) somebody immediately says "offline!" -- i.e., have that discussion after the meeting. I can see that the motivation is to avoid wasting the whole team's time on a discussion that only needs two or three people; but suppressing discussion can hurt too, as it stops people learning about tricky issues outside of their immediate work area. It would be helpful to have some rules of thumb to show when you're doing Agile wrong. Probably those exist already -- anyone got a good link? And probably "too many people in the standup meeting" is a good rule of thumb! Dragging on for an hour sounds absolutely awful. I'd even say more than about six people is too many.
- AnimalMuppet 10y ago
  I've been in a situation where we did agile with 30 people. Standup took 10-15 minutes.
  - iainmerrick 10y ago
    Did it work well?
    - AnimalMuppet 10y ago
      Extremely. You'd take ten seconds to say what you had to say. Sometimes you'd say "I need help with SQL", say, and someone would say "I'll help", and you'd be done. But we had a real agile guru on the team. We didn't do "Agile Methodology" exactly; we did Extreme Programming, and we kept tweaking it. Sometimes he'd say "let's try changing our approach in this way for the next two iterations, and see how it works out". We'd do the experiment, and keep the changes or not. We kept hacking and experimenting with the process, in a controlled way, but never in a "this is how it's done" way. So if you have an "Agile is the one right way" person trying to run your team with big-A Agile, and he/she wants to do 30-person standups, you're probably in trouble...
      - iainmerrick 10y ago
        Sounds great! Keeping track of how well the process itself is working, especially, and being willing to continually tweak it to fit the team and project.
- nostrademons 10y ago
  The point of a standup is to learn that there is a tricky issue outside of your immediate work area, and to know who's got expertise on it. That way you know who to contact if "outside" becomes "inside". The actual details, you hash out in a separate meeting with just the people involved. "Offline!" is absolutely the right response if a standup starts veering into technical details. I had one team of 10 that had a problem with our standups extending into half an hour once. We resolved that we'd make the standup one minute shorter each day. After a month and a half, we had it down to a one-minute standup (6 seconds per person). It was still useful, though a bit extreme - I'd target about 5 minutes for a 10-person standup (30 seconds per).

WalterSear 10y ago

It doesn't sound like the 'Agile' team is doing standups right. There are either too many people in the room, or people are talking too much, and probably about the wrong things. And, if they are doing standups wrong, I question how much else they are cargo-culting.

reacharavindh 10y ago
Yes, everyone in there knows that scrum meetings should be short, but somehow those meetings take long, because everyone thinks their questions needs answers and their dependabcies definitely must be resolved.. so, an hour it goes.
- WalterSear 10y ago
  The point of a standup isn't to get answers or resolve dependencies - it's to make others aware of them. The first thing we do after stand ups is have a bunch of quick one-on-one or small group meetings.
- acbabis 10y ago
  Our meeting format was for each person to say a) What they worked on, b) What they were about to work on, and c) If they needed help with anything. Our rule was that you could ask for help as long as you were just scheduling a time to meet after the stand-up. It worked really, really well. Then we got a new scrum master whose desired format was to talk about each item on the Kanban board each day, even the ones that weren't being worked on.
  - lisivka 10y ago
    It's status meeting. Developers unlike status meeting, so they invented their own meeting: daily standup meeting.
- blub 10y ago
  This is really bad and a major failure on the part of the scrum master. The point of this meeting is to help the team sync on what they are doing and what they plan to do. It should take 10m at most. Any issues (blockers, dependencies, etc) should be taken to separate ad-hoc discussions to let the team get back to work.

Davertron 10y ago

Is everything else between these two groups completely equal? I seriously doubt it is, in which case I don't think it's fair to make any conclusions that hold weight. This is one of the problems I have with these sorts of things. My company went Agile about two years ago, and lots of people like to rant about how much better everything is now and how much more productive we all are because of it. Except we actually have no way of knowing whether it made any difference at all.

reacharavindh 10y ago
Sorry, I should have made it clearer. I ranted likea personal thought than a definitive statement. The teams work on different projects. The diversity and experience of its members are different. They are not strictly comparable. But, looking at both teams from above, it feels like the non agile team is very simple and it works. The agile team is more complicated and works only on paper.
- piva00 10y ago
  From my personal experience: experienced teams can thrive with almost no methodology and an ad-hoc process because... They had experience with other processes and can see the good and bad in them. I still advocate agile for less homogeneous teams or in situations like other posts have highlighted but a team of more senior developers with a working process that is open to be improved (one of the cornerstones of agile) will thrive with less churn than when forced into a by-the-book agile process.
  - meheleventyone 10y ago
    For me Agile is by definition an ad-hoc process just one with guiding principles for how to go about organising it. The problem comes with formalised methodologies based on Agile which are treated as a one size fits all approach for any team.

solipsism 10y ago

Seems like people think using Agile and using your brain is an either-or kind of thing. It's not magic.

UK-AL 10y ago

Scrum != Agile. Heck its sounds if your doing scrum wrong anyhow. Kanban board, prioritization, CI + CD, automated tests is probably about as much agile as most companies need.

iainmerrick 10y ago

One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. The ad-hoc approach also sounds quite agile (at least with a small 'a'). It's certainly closer to Agile than to Waterfall, assuming they didn't do a big design up front before writing any code. I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process.

btilly 10y ago
But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process. But of course. If you just cherry-pick and experiment, then you won't have any reason to pay an expensive expert to tell you how to do it right!
strken 10y ago
I'm not a huge fan of Scrum, but there's a grain of truth in there. If you're forced to use the whole thing, it's harder to creatively misinterpret the underlying spirit by e.g. having one hour "standups" where everyone is sitting down, having a backlog that covers a year of work in excruciating detail, or estimating in hours then using those estimates to fire people.
squeaky-clean 10y ago
> I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process. I'm a big Scrum fan (when it works), and my biggest takeaway is that it's exactly meant for cherry-picking and modifying. The best team I've ever been on was one where we were all using Scrum for the first time. We were constantly trying to mold it to fit us best, and it ended up looking nothing like the original model of Scrum. It was also the only time I've ever been on a Scrum team that did proper retrospectives, which I think is the biggest point! Pretty much every other team has either ignored it ("Why do we need to discuss Scrum, it's in the book and laid out for us.") or merged it with the Review, so that managers, stakeholders, and people outside the team are involved in that. And no one wants to suggest changes or raise complaints with outsiders watching. Too many people seem to read a book about Scrum, memorize all the concepts and rules and abide by it, without reading any of the justification behind it. If you swear we need story points, and they need to follow a fibonacci scale, but you can't tell me why story points are better than estimating hours, you're doing it wrong (and then points always get fucking conflated with hours anyways). If you understand that story points are just one way of estimating a task's effort relative to other tasks, and that relative estimates tend to be easier to make, and scale better with all the other estimates when things change, then you're allowed to make the call of whether story points are best for the team, or a different estimating system, or none at all. Even better than someone understanding that, everyone on the team should understand that and be able to weigh in.

mfrommil 10y ago

A "1 hour daily standup" is not agile. The point of a stand-up is just that... everyone can stand because the meeting is so short. Ideally 15 minutes max.

iainmerrick 10y ago
It's annoying when people get really dogmatic about having to stand up in the stand-up meeting. I know it's supposed to remind and encourage everyone to keep the meeting short, but in my experience that simply doesn't work.
- dood 10y ago
  Agreed, enforcing standing up but not brevity is the worst way to do standups, and a clear sign of pure cargo-culting.
- AnimalMuppet 10y ago
  Maybe not. But have a culture that the meeting really is that short, and let people sit if they want to.
  - iainmerrick 10y ago
    Agreed. Don't force people to stand, keep it so short and sweet so that people want to stand.

transitorykris 10y ago

Nowhere does Agile say you have to do standups or measure velocity :) At some point the team that's inventing its own process will find it stops working, what's important is if they can identify when that happens and find new ways of getting things done. http://agilemanifesto.org/ http://agilemanifesto.org/

vorpalhex 10y ago

Agile is a very loaded word. One meaning of Agile is a very specific kind of process, the other meaning and perhaps closer to the original manifesto is what you're describing with the "non-agile" team.

RandomOpinion 10y ago

> I can visibly tell the devs walking out of the room spend more time worrying about "velocity" and "organisation of work" than the money making work that needs to be done. It almost feels like the agile process gives them "one more job" of picking the doable things from the list of stuff that needs to be done so they look better than their peers with better velocity. Classic symptom of managers using agile as a (micro)management tool. Velocity, burndown charts, etc. are meant to be used by the team as a self-calibration tool. Managers do not get a say in what they think the velocity should be, either for the team or for individuals. If they do so, they create an incentive (let's be blunt, an overwhelming incentive) for the team/individuals to game them and that way lies madness. (As an aside, the best response I've ever seen to this type of dysfunction is a team who simply decided to retcon the charts on the fly to make the work committed to match the work done. Management was happy that the burndown chart was right on target, developers were free to be fully productive instead of worrying about what their velocity looked like; it was a win-win solution all around.)

dcminter 10y ago
I was once on a project where an "agile" team, at the behest of their managers, held a sprint "to improve velocity." I kid you not. I will add that I was not on that team. Our scrum master, who was excellent, shielded us entirely from the management madness.
- ci5er 10y ago
  What was the idea behind this? Spending some dedicated time knocking through some accumulated crud? (I think people call it 'technical debt' these days). Is that a bad thing?
  - dcminter 10y ago
    Nope. That I could have respected and would have made some sense. It was code for "the team will work longer hours and over the weekend so that an arbitrary number is higher."

deleted 10y ago

[deleted]

jjuel 10y ago

The reason it is referred to as a stand up is because it is short and you stand up for the whole thing. An hour long meeting is just that an hour long meeting. Something is not working right in that agile situation which is why they aren't happy.

squeaky-clean 10y ago

Just because someone says they're using Agile doesn't actually mean it. Your non-agile team sounds much closer to the actual goals of "Agile".

user5994461 10y ago

Agile is not a method. It's just a buzzword.

sydd 10y ago

You are not doing agile. In a daily scrum you cannot have conversations, its just everyone stating 3 things: What I was working on yesterday, what I will do today, and whether I need help today from someone. For a team of 10 people (a large agile team!) it should not last for more than 15 mins. I guess other parts are broken too, if they dont even know how to do a standup.