6 ms·

Usually, the more a team advertise itself as Agile, the less agility it actually has. I myself have never seen Agile work well, not even close. I saw plenty of

Usually, the more a team advertise itself as Agile, the less agility it actually has. I myself have never seen Agile work well, not even close. I saw plenty of make-believe and head-in-the-sand and as mentioned in earlier comments, insane amounts of cargo culting. I really like the way Dave Thomas put it: https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ He also made a talk about it: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M These days this is the only methodology I follow and it works wonders, anything more I feel is just noise. At the end of the day nothing replaces actual engineering and understanding what you're doing.

at-fates-hands 10y ago
>> I myself have never seen Agile work well, not even close. My main gripe is most organizations I've worked in were usually in the transition between waterfall and some form of agile. The #1 issue was the people who sold the corporate execs on agile being faster and more efficient than waterfall have set unrealistic expectations as to deadlines and release dates. Suddenly taking 12 months to build that app you were thinking of developing via waterfall, just got cut in half because everybody thought agile is so much faster, when in reality, it really isn't that much faster at all - just a different methodology, which a lot of people forget. I have yet to work at a place that has released anything any faster than how it could be done using traditional waterfall methodology. My last point about agile is that I've found it doesn't scale well. When I used agile in smaller teams (10-15 people, 3-5 devs) it was very effective. As you scale up (50+ people, 15+ devs) things slow down, inefficiencies are created because instead of several devs working on larger chunks, you have several dozen devs working on really small parts that get coded completely differently, then sometimes don't work together and it causes multiple iterations of design that wouldn't happen in waterfall. There is an advantage with us devs seeing the larger picture and coding to that, instead of this little component that gets coded 10 different ways.
- UK-AL 10y ago
  I find if you define the way things must integrate(REST) with defined versioned interfaces. Then you can have small teams working on different services, without that much overhead.
  - jeremiep 10y ago
    There are way, way, way more uses of programming than simple CRUD services. Operating systems, game engines and browsers are only 3 examples where that doesn't apply, at all :) Besides, what's to say there wont be overlap in these newly separated services that will generate work in double because teams dont talk to each other? Or maybe you'll generate two average solutions instead of a better unified one. Even with multiple teams working on different aspects of a project, you still need yet another team to maintain the global vision of the thing. To make sure everything is consistent, to avoid work duplication, to consolidate solutions and abstractions and whatnot. Its fair to say the larger a development team is, the harder it will be to manage. Its even more true with large teams of average developers, which really is the norm when you think of it. At the end of the day, communication is key.
- BurningFrog 10y ago
  I think all methodologies slow down when the teams get larger. In the XP teams I've been on, everybody rotates between stories and swap pairs daily, just to avoid the individual code ownership and fragmented coding styles you mention. Works really well. > unrealistic expectations as to deadlines and release dates. Also, one of the core agile ideas in my world is that there are no deadlines or release dates for specific features.
  - wpietri 10y ago
    > Also, one of the core agile ideas in my world is that there are no deadlines or release dates for specific features. 100% agreed. This is one of those things that so many companies can't even conceive of. But once you get people converted, it works so much better.
    - jeremiep 10y ago
      Thats usually not possible. We're not doing pure science, we're doing engineering - which happens to mix science AND economics. This means the "no deadlines" wet dream is usually a recipe for "oh shit, we ran out of money" for most projects. Also programmers are usually big babies; give them unlimited time and they'll give you unlimited bloat. Other than doing R&D it usually is impossible to have no deadlines. Most people are not doing R&D, but when you really do your government usually has programs to finance it. That's precisely how you can afford to not have deadlines because your company is paid to advance the state of the art. And even then you usually get paid after the project is over and after you've filled a bunch of forms to clearly state the problem, your solution as well as existing work in the area and why it did not apply to your case. Or if you're doing servicing work you get paid by shipping at predetermined milestones. Building software is a LOT more complex than just writing down the code and too many developers are clueless when it comes to politics, economics or management. I used to think the same when I was still new to the software industry. It took me years to understand theres a whole world around programming required for programming to happen in the first place.
      - BurningFrog 10y ago
- wpietri 10y ago
  Yeah, I definitely agree that a popular reason for adoption was "go faster", which was poisonous to the actual attempt. Honestly, I think you eventually can get substantial speed gains. But you mostly get them by cutting out waste. Doing that takes a fair bit of time and work. And not just work, but commitment to personal and cultural change. People don't do that under strong time pressure; instead they are inclined to revert to previous behavior.
flukus 10y ago
> Usually, the more a team advertise itself as Agile, the less agility it actually has. Bingo. Usually when you ask them what agile processes they are following they just mumble something about daily stand ups (which I'd argue are not agile at all). I've seen agile work. But it's more about automating builds, having continuous (or near continuous) deployments, having database migrations to easily integrate others changes, etc. My evaluation of how agile a company consists of "When a trivial bug is reported, how long until the fix is in production?". If the answer is greater than a day then they aren't agile.
- jeremiep 10y ago
  I feel like "agile processes" is an oxymoron. Real, actual agility requires a lot of thinking; something usually prevented by having processes in the first place. A better question to ask an "Agile" team would be: "what problems are you trying to solve?" - most of the time they haven't taken the time to properly analyze the problem in the first place, even when the project is near completion. They just run with dumb user-stories and start piling up Jira tasks with no clear vision. At this point I don't believe Agile can work whatsoever. A success rate of one in a thousand projects, which usually happens to be a dead-simple CRUD app anyways, means absolutely nothing, other than it has failed in a spectacular way. If software development was an actual science instead of a pop culture, the scientific method would've thrown Agile out the window decades ago. Your last two sentences almost exclusively applies to web services, which is a tiny fraction of what software engineering can do. For me real agility is how much effort you're willing to spend upfront to properly analyze problems before attacking them, how quickly do you adapt your solution when new facts become known. Its dead-easy to have agility at the beginning of a project, what matters is still having it 2 years down the road and more. Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility.
  - flukus 10y ago
    The last two sentences don't only apply to web based projects, they can apply to any application development from web to desktop to mobile. I think that would cover the vast majority of software developers. > Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility. The help in the sense that you can make and deploy changes seamlessly. For understanding code the unit tests that go along with them also help tremendously, if they are well written unit tests anyway.

at-fates-hands 10y ago

>> I myself have never seen Agile work well, not even close. My main gripe is most organizations I've worked in were usually in the transition between waterfall and some form of agile. The #1 issue was the people who sold the corporate execs on agile being faster and more efficient than waterfall have set unrealistic expectations as to deadlines and release dates. Suddenly taking 12 months to build that app you were thinking of developing via waterfall, just got cut in half because everybody thought agile is so much faster, when in reality, it really isn't that much faster at all - just a different methodology, which a lot of people forget. I have yet to work at a place that has released anything any faster than how it could be done using traditional waterfall methodology. My last point about agile is that I've found it doesn't scale well. When I used agile in smaller teams (10-15 people, 3-5 devs) it was very effective. As you scale up (50+ people, 15+ devs) things slow down, inefficiencies are created because instead of several devs working on larger chunks, you have several dozen devs working on really small parts that get coded completely differently, then sometimes don't work together and it causes multiple iterations of design that wouldn't happen in waterfall. There is an advantage with us devs seeing the larger picture and coding to that, instead of this little component that gets coded 10 different ways.

UK-AL 10y ago
I find if you define the way things must integrate(REST) with defined versioned interfaces. Then you can have small teams working on different services, without that much overhead.
- jeremiep 10y ago
  There are way, way, way more uses of programming than simple CRUD services. Operating systems, game engines and browsers are only 3 examples where that doesn't apply, at all :) Besides, what's to say there wont be overlap in these newly separated services that will generate work in double because teams dont talk to each other? Or maybe you'll generate two average solutions instead of a better unified one. Even with multiple teams working on different aspects of a project, you still need yet another team to maintain the global vision of the thing. To make sure everything is consistent, to avoid work duplication, to consolidate solutions and abstractions and whatnot. Its fair to say the larger a development team is, the harder it will be to manage. Its even more true with large teams of average developers, which really is the norm when you think of it. At the end of the day, communication is key.
BurningFrog 10y ago
I think all methodologies slow down when the teams get larger. In the XP teams I've been on, everybody rotates between stories and swap pairs daily, just to avoid the individual code ownership and fragmented coding styles you mention. Works really well. > unrealistic expectations as to deadlines and release dates. Also, one of the core agile ideas in my world is that there are no deadlines or release dates for specific features.
- wpietri 10y ago
  > Also, one of the core agile ideas in my world is that there are no deadlines or release dates for specific features. 100% agreed. This is one of those things that so many companies can't even conceive of. But once you get people converted, it works so much better.
  - jeremiep 10y ago
    Thats usually not possible. We're not doing pure science, we're doing engineering - which happens to mix science AND economics. This means the "no deadlines" wet dream is usually a recipe for "oh shit, we ran out of money" for most projects. Also programmers are usually big babies; give them unlimited time and they'll give you unlimited bloat. Other than doing R&D it usually is impossible to have no deadlines. Most people are not doing R&D, but when you really do your government usually has programs to finance it. That's precisely how you can afford to not have deadlines because your company is paid to advance the state of the art. And even then you usually get paid after the project is over and after you've filled a bunch of forms to clearly state the problem, your solution as well as existing work in the area and why it did not apply to your case. Or if you're doing servicing work you get paid by shipping at predetermined milestones. Building software is a LOT more complex than just writing down the code and too many developers are clueless when it comes to politics, economics or management. I used to think the same when I was still new to the software industry. It took me years to understand theres a whole world around programming required for programming to happen in the first place.
    - BurningFrog 10y ago
wpietri 10y ago
Yeah, I definitely agree that a popular reason for adoption was "go faster", which was poisonous to the actual attempt. Honestly, I think you eventually can get substantial speed gains. But you mostly get them by cutting out waste. Doing that takes a fair bit of time and work. And not just work, but commitment to personal and cultural change. People don't do that under strong time pressure; instead they are inclined to revert to previous behavior.

flukus 10y ago

> Usually, the more a team advertise itself as Agile, the less agility it actually has. Bingo. Usually when you ask them what agile processes they are following they just mumble something about daily stand ups (which I'd argue are not agile at all). I've seen agile work. But it's more about automating builds, having continuous (or near continuous) deployments, having database migrations to easily integrate others changes, etc. My evaluation of how agile a company consists of "When a trivial bug is reported, how long until the fix is in production?". If the answer is greater than a day then they aren't agile.

jeremiep 10y ago
I feel like "agile processes" is an oxymoron. Real, actual agility requires a lot of thinking; something usually prevented by having processes in the first place. A better question to ask an "Agile" team would be: "what problems are you trying to solve?" - most of the time they haven't taken the time to properly analyze the problem in the first place, even when the project is near completion. They just run with dumb user-stories and start piling up Jira tasks with no clear vision. At this point I don't believe Agile can work whatsoever. A success rate of one in a thousand projects, which usually happens to be a dead-simple CRUD app anyways, means absolutely nothing, other than it has failed in a spectacular way. If software development was an actual science instead of a pop culture, the scientific method would've thrown Agile out the window decades ago. Your last two sentences almost exclusively applies to web services, which is a tiny fraction of what software engineering can do. For me real agility is how much effort you're willing to spend upfront to properly analyze problems before attacking them, how quickly do you adapt your solution when new facts become known. Its dead-easy to have agility at the beginning of a project, what matters is still having it 2 years down the road and more. Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility.
- flukus 10y ago
  The last two sentences don't only apply to web based projects, they can apply to any application development from web to desktop to mobile. I think that would cover the vast majority of software developers. > Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility. The help in the sense that you can make and deploy changes seamlessly. For understanding code the unit tests that go along with them also help tremendously, if they are well written unit tests anyway.