5 ms·

>> 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 waterfal

>> 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.

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.