4 ms·

I've unfortunately never seen Agile work. I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile

by lawl 11y ago

I've unfortunately never seen Agile work. I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. That actually worked well for a year, until management had to fix it, because we weren't Agile. We actually went from 2hrs of meetings/week to almost two full days, I'm not shitting you (to be fair, they went a bit back on that and cut it down to one day fairly quickly, but we still wasted more time by becoming more Agile). Then my job was to fix others peoples projects from companies that weren't familiar with the technology they used as a consultant. All of them were agile, SCRUM and SCRUM of SCRUM. And it just didn't work, Ive never seen such dysfunctional teams before. Nothing worked. I realize I've probably only seen the bad side of SCRUM because whenever I got called in they were behind schedule and already fucked up the project anyways. I think SCRUM can work, maybe, hopefully. But to this day I have yet to see it happen. You have to do it right, and even with basically zero experience with SCRUM I was able to tell that they weren't doing it right, they were just wasting time and not having ANY coordination whatsoever. I think what others have said here is right, if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you.

wavefunction 11y ago
What you've described is not agile in my opinion nor does it conform to the principles laid out by the manifesto. I worked in what I consider to be a truly agile/scrum team and we had two week iterations with five minute standups each morning and a thirty minute demo on the last Friday of each iteration followed by an hour of planning poker to estimate items on the backlog. Then we left for the weekend, ready to start a new iteration the following Monday. The rest of our time was direct development and we (three developers 1 QA and 1 PM) created a great SAAS product in nine months from start to finish. The best part was that we were making an agile planning tool so when we got far enough into the project, we started using our project to plan its own development.
jakejake 11y ago
We use our version of SCRUM with pretty good results for our maintenance and small features. For large projects though, we wind up with a bit of BDUF just to get a grip on what we're building. That ultimately morphes into our agile process as we get closer to the release. It's certainly not the "right" way to do it, but it works very well for us. Shops that are 100% full-on SCRUM seem to me to be mired in process, which is ironic.
Retric 11y ago
All Scrum does is make it harder to lie. On great teams this seems redundant and on incompetent teams it's not that useful. However, on average teams someone is often lying which can cause a lot of issues.
weego 11y ago
because we weren't agile It sounds to me like you were agile, but not Agile. Capital A Agile has seminars and books and you can interview Agile PM candidates easily and people can feed confident "going forwards". Lowercase a agile has a lot of intangibles and can be hard to replicate if you have a turnover of staff. Both can suck, both can work. I was once told I couldn't remove a task from the board and dump it in the bin because that's not how Agile works, but what could be more agile than quickly cutting out work we didn't need to do?
- organsnyder 11y ago
  I also use the Agile vs. agile distinction. Big-A Agile is a product, while little-a agile is a philosophy. If you're blindly subscribing to the processes espoused by thought leaders, you're going to have problems no matter how good the philosophy. You need to be constantly evaluating, retrospecting, and iterating on your processes to make sure that they're the best they can be for your particular situation.
- lawl 11y ago
  Good point, edited my post.
lojack 11y ago
> we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. Interestingly enough, I find that to be something more in line with agile than the way most teams treat agile process. The agile manifesto itself event says: > Individuals and interactions over Processes and tools Which in a way makes most agile processes a sort of oxymoron. At the end of the day we just need to understand that we're building software, and we need to do more of what helps us build software and less of what prevents us from building software. Agile (or what people call agile) can do both.
- lawl 11y ago
  This. Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case. Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead. Most people will look at you in a weird way when you tell them you had 20 devs in one team. But what can I say, it certainly worked better than the other things we tried. As I said, I'm sure it can work, but you need to do it right, and we certainly didn't.
- dragonwriter 11y ago
  > Which in a way makes most agile processes a sort of oxymoron. There's no "sort of" about it. Rigid, context-blind processes -- whether sold as "Agile" or not -- are exactly what Agile is a reaction against. No process is Agile, and a team is only Agile insofar as it evaluates what works for the particular team in the particular context and places that ahead of preconceptions about what process should be that derive from other sources.
mrbird 11y ago
Like any other set of knowledge, the real skill lies on knowing when and how to apply it. When asked to describe our process, I summarize it as "minimalist Scrum." To us, that means using some aspects of Scrum (small team sizes, prioritized work backlogs, and daily standups) and ignoring others (anything with the word "sprint" in it, pre-planned release cycles, and velocity estimation/tracking). Our culture is more built around continuous deployment. We've found the process that works well for us, and I encourage everyone to be thoughtful and consider many approaches as they try to do the same.
dragonwriter 11y ago
> I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. Actually, having a team evolve its own process that works for the team is agile. That's all and exactly what the Agile manifesto calls for. > That actually worked well for a year, until management had to fix it, because we weren't Agile. Having management intervene and institute a process based on external, process-based preferences rather than evaluation by the team of what is and isn't working for the particular team in the particular context is exactly what the Agile Manifesto was a reaction against. Agile was working for your team, then management came in and -- through an apparent lack of understanding of both what your team was doing, what worked for your team, and what Agile is -- did exactly what Agile is defined in opposition to, and broke it.
- jerf 11y ago
  And, since many seem here to be too busy slagging on "Agile" to RTFA, note that the solution being proposed in the article is essentially to try to create a methodology that consists solely of "you have to grow your own methodology using evidence and adaptation", so that there's nothing left to hijack. Personally I think the author underestimates the ability of management to turn good ideas into checklists wholly divorced from the original idea, but it's at least an attempt. But the fact that people decry psuedo-Agile with exactly the same criticisms that technically "Agile" was supposed to be is indeed some pretty strong evidence that "Agile" has failed to accomplish its original goals. Note I say this without regard to whether Agile in either form is "correct". It's just that things are what they are, and there's definitely a great deal of difference between what the Agile Manifesto, a real document that exists in the real world using real words that aren't just "whatever somebody says they are" [1], and "whatever processes some team somewhere developed that may or may not have worked for them and are not being blindly applied to your team because I say that's 'Agile' and you can't object, because it's 'Agile'". I wouldn't get emotional if you want to claim both are bad things and bad ideas, I will only say here that they are not the same idea. [1]: http://agilemanifesto.org/ http://agilemanifesto.org/
  - lawl 11y ago
    Yes, I am guilty of this. I had too many bad experiences, so I never bothered. This thread in general convinced me, I've done that now :) I should have done this sooner, but I expected some tl;dr management stuff. If I had done so sooner I could at least have told them they're not Agile, and back it up.
deleted 11y ago
[deleted]
LordHumungous 11y ago
> if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you I agree, however most teams fall somewhere between great and bad. Also, there may be many different stake holders and changing requirements in a project. In these circumstances some discipline is needed to ensure that developer hours are used wisely. The options here are: 1. No process. Rely on the team to self-organize. 2. A waterfall like process (All planning up front, long term development goals 3. An agile like process (Short term development benchmarks, daily stand ups, constant re-evaluation of goals) Of the three, the first works well for a very small team, or a truly excellent teams. A bad team is going to fail no matter which is chosen. But, for teams in between, or for projects where there is confusion about requirements, I'd argue that option three is clearly the best of the bunch.
wpietri 11y ago
I have seen Agile approaches work (in particular, I've seen and been on some great Extreme Programming teams), but I believe your Agile experience is the most common these days. What I see most often is bullshit labels slapped on the old idiocy. However, I think this is mostly bunk: "If you have a great team, it will organize itself anyway." I think you can get to some level of adequacy that way. But doing better requires conscious practice, a shared understanding of how the team works, and a disciplined approach to inspecting and adapting. That just doesn't happen with the laissez faire sort of self-organization. Most of the assorted Agile processes came out of teams acting like that and then saying, "Hey, let's define and publish what we're doing." You're right that jumping on an Agile bandwagon doesn't help, but there are other ways to make use of Agile philosophy and practices than blind bandwagon-jumping.
ollysb 11y ago
I've used some form of agile process on every project that I've ever worked. On every project we've shipped features at a good pace and managed to keep on top of test coverage and technical debt. There's obviously a lot of people that have had bad experiences though. How do these problems manifest on the projects where you've seen agile fail?

by lawl 11y ago

wavefunction 11y ago

What you've described is not agile in my opinion nor does it conform to the principles laid out by the manifesto. I worked in what I consider to be a truly agile/scrum team and we had two week iterations with five minute standups each morning and a thirty minute demo on the last Friday of each iteration followed by an hour of planning poker to estimate items on the backlog. Then we left for the weekend, ready to start a new iteration the following Monday. The rest of our time was direct development and we (three developers 1 QA and 1 PM) created a great SAAS product in nine months from start to finish. The best part was that we were making an agile planning tool so when we got far enough into the project, we started using our project to plan its own development.

jakejake 11y ago

We use our version of SCRUM with pretty good results for our maintenance and small features. For large projects though, we wind up with a bit of BDUF just to get a grip on what we're building. That ultimately morphes into our agile process as we get closer to the release. It's certainly not the "right" way to do it, but it works very well for us. Shops that are 100% full-on SCRUM seem to me to be mired in process, which is ironic.

Retric 11y ago

All Scrum does is make it harder to lie. On great teams this seems redundant and on incompetent teams it's not that useful. However, on average teams someone is often lying which can cause a lot of issues.

weego 11y ago

because we weren't agile It sounds to me like you were agile, but not Agile. Capital A Agile has seminars and books and you can interview Agile PM candidates easily and people can feed confident "going forwards". Lowercase a agile has a lot of intangibles and can be hard to replicate if you have a turnover of staff. Both can suck, both can work. I was once told I couldn't remove a task from the board and dump it in the bin because that's not how Agile works, but what could be more agile than quickly cutting out work we didn't need to do?

organsnyder 11y ago
I also use the Agile vs. agile distinction. Big-A Agile is a product, while little-a agile is a philosophy. If you're blindly subscribing to the processes espoused by thought leaders, you're going to have problems no matter how good the philosophy. You need to be constantly evaluating, retrospecting, and iterating on your processes to make sure that they're the best they can be for your particular situation.
lawl 11y ago
Good point, edited my post.

lojack 11y ago

> we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. Interestingly enough, I find that to be something more in line with agile than the way most teams treat agile process. The agile manifesto itself event says: > Individuals and interactions over Processes and tools Which in a way makes most agile processes a sort of oxymoron. At the end of the day we just need to understand that we're building software, and we need to do more of what helps us build software and less of what prevents us from building software. Agile (or what people call agile) can do both.

lawl 11y ago
This. Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case. Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead. Most people will look at you in a weird way when you tell them you had 20 devs in one team. But what can I say, it certainly worked better than the other things we tried. As I said, I'm sure it can work, but you need to do it right, and we certainly didn't.
dragonwriter 11y ago
> Which in a way makes most agile processes a sort of oxymoron. There's no "sort of" about it. Rigid, context-blind processes -- whether sold as "Agile" or not -- are exactly what Agile is a reaction against. No process is Agile, and a team is only Agile insofar as it evaluates what works for the particular team in the particular context and places that ahead of preconceptions about what process should be that derive from other sources.

mrbird 11y ago

Like any other set of knowledge, the real skill lies on knowing when and how to apply it. When asked to describe our process, I summarize it as "minimalist Scrum." To us, that means using some aspects of Scrum (small team sizes, prioritized work backlogs, and daily standups) and ignoring others (anything with the word "sprint" in it, pre-planned release cycles, and velocity estimation/tracking). Our culture is more built around continuous deployment. We've found the process that works well for us, and I encourage everyone to be thoughtful and consider many approaches as they try to do the same.

dragonwriter 11y ago

> I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. Actually, having a team evolve its own process that works for the team is agile. That's all and exactly what the Agile manifesto calls for. > That actually worked well for a year, until management had to fix it, because we weren't Agile. Having management intervene and institute a process based on external, process-based preferences rather than evaluation by the team of what is and isn't working for the particular team in the particular context is exactly what the Agile Manifesto was a reaction against. Agile was working for your team, then management came in and -- through an apparent lack of understanding of both what your team was doing, what worked for your team, and what Agile is -- did exactly what Agile is defined in opposition to, and broke it.

jerf 11y ago
And, since many seem here to be too busy slagging on "Agile" to RTFA, note that the solution being proposed in the article is essentially to try to create a methodology that consists solely of "you have to grow your own methodology using evidence and adaptation", so that there's nothing left to hijack. Personally I think the author underestimates the ability of management to turn good ideas into checklists wholly divorced from the original idea, but it's at least an attempt. But the fact that people decry psuedo-Agile with exactly the same criticisms that technically "Agile" was supposed to be is indeed some pretty strong evidence that "Agile" has failed to accomplish its original goals. Note I say this without regard to whether Agile in either form is "correct". It's just that things are what they are, and there's definitely a great deal of difference between what the Agile Manifesto, a real document that exists in the real world using real words that aren't just "whatever somebody says they are" [1], and "whatever processes some team somewhere developed that may or may not have worked for them and are not being blindly applied to your team because I say that's 'Agile' and you can't object, because it's 'Agile'". I wouldn't get emotional if you want to claim both are bad things and bad ideas, I will only say here that they are not the same idea. [1]: http://agilemanifesto.org/ http://agilemanifesto.org/
- lawl 11y ago
  Yes, I am guilty of this. I had too many bad experiences, so I never bothered. This thread in general convinced me, I've done that now :) I should have done this sooner, but I expected some tl;dr management stuff. If I had done so sooner I could at least have told them they're not Agile, and back it up.

deleted 11y ago

[deleted]

LordHumungous 11y ago

> if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you I agree, however most teams fall somewhere between great and bad. Also, there may be many different stake holders and changing requirements in a project. In these circumstances some discipline is needed to ensure that developer hours are used wisely. The options here are: 1. No process. Rely on the team to self-organize. 2. A waterfall like process (All planning up front, long term development goals 3. An agile like process (Short term development benchmarks, daily stand ups, constant re-evaluation of goals) Of the three, the first works well for a very small team, or a truly excellent teams. A bad team is going to fail no matter which is chosen. But, for teams in between, or for projects where there is confusion about requirements, I'd argue that option three is clearly the best of the bunch.

wpietri 11y ago

I have seen Agile approaches work (in particular, I've seen and been on some great Extreme Programming teams), but I believe your Agile experience is the most common these days. What I see most often is bullshit labels slapped on the old idiocy. However, I think this is mostly bunk: "If you have a great team, it will organize itself anyway." I think you can get to some level of adequacy that way. But doing better requires conscious practice, a shared understanding of how the team works, and a disciplined approach to inspecting and adapting. That just doesn't happen with the laissez faire sort of self-organization. Most of the assorted Agile processes came out of teams acting like that and then saying, "Hey, let's define and publish what we're doing." You're right that jumping on an Agile bandwagon doesn't help, but there are other ways to make use of Agile philosophy and practices than blind bandwagon-jumping.

ollysb 11y ago

I've used some form of agile process on every project that I've ever worked. On every project we've shipped features at a good pace and managed to keep on top of test coverage and technical debt. There's obviously a lot of people that have had bad experiences though. How do these problems manifest on the projects where you've seen agile fail?