4 ms·

> 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

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

by trimbo 6y ago

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.