4 ms·

For the past several years now, each time I join a new team or project, my first objective is to detach and destroy the "Agile" process workflow. When you fina

by vbtemp 6y ago

For the past several years now, each time I join a new team or project, my first objective is to detach and destroy the "Agile" process workflow. When you finally liberate a team from Agile, it's just breathtaking how much you can focus on delivering working software that gets deployed with quick iterations that's closely aligned with the business and customer's needs. When free from the tyranny of Agile, teams can be effectively self-organize, remove micro-managers, and quickly adapt to changing needs and requirements. My experience is that staff are usually much happier, more productive, and less stressed once agile is gone. I mean contemporary Agile as pushed by corporations and those awful "coaches" (who never seem to be actual developers) --- if you were you design a system whose end goal was making great developers unhappy, unproductive and locked into a dysfunctional system, Agile would be it.

trimbo 6y ago
> it's just breathtaking how much you can focus on delivering working software that gets deployed with quick iterations that's closely aligned with the business and customer's needs That's literally the agile manifesto. "Scrum" is one implementation of what agile was trying to achieve. Maybe that's what you're thinking of?
- vbtemp 6y ago
  > That's literally the agile manifesto. I know, that's the irony. Agile as pushed today ends up with the compete anithesis of that. It's the difference between "Agile" (Capital A), and "agile"
- balfirevic 6y ago
  Parent's post so closely resembles the agile manifesto that it's got to be on purpose.
- Jtsummers 6y ago
  There's Big-A Agile and agile. The manifesto is really the latter, the former is a set (different depending on where you are) of very specific practices that neglect the principles in the manifesto (though, typically, they were derived from them originally). Read SAFe Distilled or SAFe 4.5 Reference Guide for what happens in large enterprises (god SAFe is a fuck up). It consists of some good ideas, but also some very explicit practices that don't help in every effort (and sometimes hurt). It is literally the opposite of Agile, which is supposed to be about flexibility. If you want to hear about its "success", just remember it was used for F-35's software... Big-A Agile is based on the belief that adoption of practices is sufficient, and that deep understanding is unnecessary. This is the realm of cargo cults.
  - vbtemp 6y ago
    > If you want to hear about it's "success", just remember it was used for F-35's software... This is the example I use all the time!! Maybe agile is great when you're making an online shopping cart for a e-commerce website, but the idea of using Agile for complex, engineered systems is laugh-out-loud hysterically absurd. And this does not just mean spaceflight software, it basically means anything more sophisticated than a CRUD app.
    - dankoss 6y ago
      Totally agree. I believe Agile works well in environments with shallow tech stacks, but it has worked terribly in my experience in product companies that build hardware, FPGA dev, embedded software, and other disciplines that can't deliver on two week increments or increments that align well with other disciplines.
      - Jtsummers 6y ago
        Agile can work well in embedded, I've seen and done it. The thing people have to forget is the notion of "deliver on two week increments". It's not about delivering a product that can be fielded each increment, in the case of an embedded system, but about delivering something that has some improvement or new testable component. I can't make an embedded radio handle, in two weeks, a completely new message type (well, depends). But I can do things in each two week interval that is verifiable. I can show that I've actually received the new message, that I can send it back out, that I can pass it through the various internal processors (if multiple processors are used) or processes (if a single one). Then I can start transforming it, storing it, changing other things about the radio state based on the message contents. Each of those is independently verifiable and completable within a short period of time. But taken as a whole, it's a 6-month project. The agile way has you make those small things, verify them, and then move on to the next thing. I can deliver (to the test team, to others using the system) the partially-completed system, it just can't be fielded (and that's fine). And that's not unique to embedded. If you only focus on things that can be fielded in each increment, you'll never develop the more complex tasks, or address the tech debt.
bjohnson225 6y ago
I never really understood the amount of criticism aimed at agile by developers until I switched to a large enterprise. I feel like I’ve gone from a company focused on delivering working software which was supported by the common agile practices to a company which is Agile, really wants you to know just how Agile it is in every other company email, and one where our team will only be judged based on how Agile we truly are. For example, there are days towards the end of the sprint when I’m not allowed to pick up new work and the infinite wisdom of the agile coach is that a ‘clean’ board by the end of the sprint is the what we’re really being paid to deliver (and starting something else would compromise that). This runs alongside serious customer deadlines which are hidden by the dates the Agile program runs by.

by vbtemp 6y ago

trimbo 6y ago

> it's just breathtaking how much you can focus on delivering working software that gets deployed with quick iterations that's closely aligned with the business and customer's needs That's literally the agile manifesto. "Scrum" is one implementation of what agile was trying to achieve. Maybe that's what you're thinking of?

vbtemp 6y ago
> That's literally the agile manifesto. I know, that's the irony. Agile as pushed today ends up with the compete anithesis of that. It's the difference between "Agile" (Capital A), and "agile"
balfirevic 6y ago
Parent's post so closely resembles the agile manifesto that it's got to be on purpose.
Jtsummers 6y ago
There's Big-A Agile and agile. The manifesto is really the latter, the former is a set (different depending on where you are) of very specific practices that neglect the principles in the manifesto (though, typically, they were derived from them originally). Read SAFe Distilled or SAFe 4.5 Reference Guide for what happens in large enterprises (god SAFe is a fuck up). It consists of some good ideas, but also some very explicit practices that don't help in every effort (and sometimes hurt). It is literally the opposite of Agile, which is supposed to be about flexibility. If you want to hear about its "success", just remember it was used for F-35's software... Big-A Agile is based on the belief that adoption of practices is sufficient, and that deep understanding is unnecessary. This is the realm of cargo cults.
- vbtemp 6y ago
  > If you want to hear about it's "success", just remember it was used for F-35's software... This is the example I use all the time!! Maybe agile is great when you're making an online shopping cart for a e-commerce website, but the idea of using Agile for complex, engineered systems is laugh-out-loud hysterically absurd. And this does not just mean spaceflight software, it basically means anything more sophisticated than a CRUD app.
  - dankoss 6y ago
    Totally agree. I believe Agile works well in environments with shallow tech stacks, but it has worked terribly in my experience in product companies that build hardware, FPGA dev, embedded software, and other disciplines that can't deliver on two week increments or increments that align well with other disciplines.
    - Jtsummers 6y ago
      Agile can work well in embedded, I've seen and done it. The thing people have to forget is the notion of "deliver on two week increments". It's not about delivering a product that can be fielded each increment, in the case of an embedded system, but about delivering something that has some improvement or new testable component. I can't make an embedded radio handle, in two weeks, a completely new message type (well, depends). But I can do things in each two week interval that is verifiable. I can show that I've actually received the new message, that I can send it back out, that I can pass it through the various internal processors (if multiple processors are used) or processes (if a single one). Then I can start transforming it, storing it, changing other things about the radio state based on the message contents. Each of those is independently verifiable and completable within a short period of time. But taken as a whole, it's a 6-month project. The agile way has you make those small things, verify them, and then move on to the next thing. I can deliver (to the test team, to others using the system) the partially-completed system, it just can't be fielded (and that's fine). And that's not unique to embedded. If you only focus on things that can be fielded in each increment, you'll never develop the more complex tasks, or address the tech debt.

bjohnson225 6y ago

I never really understood the amount of criticism aimed at agile by developers until I switched to a large enterprise. I feel like I’ve gone from a company focused on delivering working software which was supported by the common agile practices to a company which is Agile, really wants you to know just how Agile it is in every other company email, and one where our team will only be judged based on how Agile we truly are. For example, there are days towards the end of the sprint when I’m not allowed to pick up new work and the infinite wisdom of the agile coach is that a ‘clean’ board by the end of the sprint is the what we’re really being paid to deliver (and starting something else would compromise that). This runs alongside serious customer deadlines which are hidden by the dates the Agile program runs by.