Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Is Dead (Long Live Agility)

pragdave.me

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Agile Is Dead (Long Live Agility)

#71

Post by sillysaurus3 »

chrisconley wrote: post #50
shadowmint wrote: post #38

Earlier quoted context omitted.

The point of that article is that you need to be self reflective and open to change. I'll post it here again, without any of the other distracting things he said about verbs and so on. Just take a moment to think about what these steps actually mean: - Find out where you are - Take a small step towards your goal - Adjust your understanding based on what you learned - Repeat If you want to work as effectively as you c…

Spot on. This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development. There are so many dogmas out there (Fail fast, MVP, Agile, Lean, etc) which all boil down to the same thing: Maximizing information gain and minimizing the cost of failure. I'm planning on a blog post/email course/talk/something in the next few…

This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development.

Oh come on, you can't tease us like that! You have a duty to satisfy our curiosity now. :)

How can hangman with decision theory apply to software development?

Re: Agile Is Dead (Long Live Agility)

#73

Post by beat »

And today, I read this oldie-but-goodie over at Martin Fowler's blog...

http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht...

In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that gets in the way of developers rather than helping them work efficiently.

And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. But process needs to be scaled to team size, talent, and risk tolerance. A broad-strokes "Agile" process that restricts competent teams is worse than useless.

Re: Agile Is Dead (Long Live Agility)

#74

Post by michaelochurch »

So much of "Agile" is an attempt to "patch" the top-down, closed-allocation organization that is simply incapable of hitting technical high notes no matter how much it spends or how many people it hires.

Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irrotational vortex, gets stronger. Then it devolves into micromanagement, as discussed here: http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-a...

The reality is that the future just has no use for closed-allocation tech companies. Every tech company needs to decide either to play for real and try to excel (open allocation, highly selective hiring) or GTFO and do something else.

Scrum is a formational hack, but closed allocation is a foundational problem and, if technical excellence is needed, a show-stopper.

Re: Agile Is Dead (Long Live Agility)

#75

Post by beat »

Meanwhile, I'm watching helplessly from the sidelines as "DevOps" becomes the next "Agile", tasting bile in my mouth and wondering when a brilliant concept for reworking the culture-clash problem between developers and operations got reduced to a "knows how to use Chef/Puppet" for recruiters.

Re: Agile Is Dead (Long Live Agility)

#77

Post by michaelochurch »

beat wrote: post #73

And today, I read this oldie-but-goodie over at Martin Fowler's blog... http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht... In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that…

And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects.

There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity generate a lot of maintenance work. (Modular design is to pay that maintenance cost upfront, which most executives don't like.) Maintenance needs to be done well, but the only thing that motivates good people to do it (instead of hopping to another team, changing jobs, or demanding a $500k+ salary) is either (a) caring about the module as a client, which means they typically aren't more than 25%-time maintainers because their main project is whatever uses the module, or (b) the possibility of gaining a national reputation in OSS.

The open-source ecosystem can motivate the kind of work that large codebases need. (That doesn't mean they never turn to crap. It means that it's not inexorable.) Corporate codebases don't have that.

Twitter hasn't open-sourced, for one example, Storm because they're nice guys (not to rag on them; this is one of a million examples I could use). That may be a factor, but the main reason is that they don't want it to turn to crap, and the open-source ecosystem is more robust against that than anything in the closed-source world. If you rely on something but it's not extremely proprietary, you should probably open source it for its own health. Proprietary stuff should probably be kept as data, not code.

Re: Agile Is Dead (Long Live Agility)

#78

Post by a_c_s »

planetjones wrote: post #13

Well said. A friend of mine is another company are supposedly moving to "Agile". Their approach is to have whole day meetings to discuss how it will work! Three months later they're still planning how their Agile, Scrum based thing will work. The conferences, the consultancies, the big companies, etc. really have destroyed the essence of the Agile manifesto in many ways.

That's why I like to make the distinction between little-a agile (the non-dogmatic vision of the original manifesto) and big-A Agile (rigid, sold as a product methodologies backed by expensive certifications).

Re: Agile Is Dead (Long Live Agility)

#79

Post by beat »

michaelochurch wrote: post #77
beat wrote: post #73

And today, I read this oldie-but-goodie over at Martin Fowler's blog... http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht... In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that…

And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity g…

That's why software organizations need to be modularized, just like code, so the small teams can work efficiently. But on the other hand, doing that just pushes complexity around. Instead of having a team chaos problem, you have an API and requirements chaos problem.

Re: Agile Is Dead (Long Live Agility)

#80

Post by chrisconley »

sillysaurus3 wrote: post #71
chrisconley wrote: post #50

Earlier quoted context omitted.

Spot on. This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development. There are so many dogmas out there (Fail fast, MVP, Agile, Lean, etc) which all boil down to the same thing: Maximizing information gain and minimizing the cost of failure. I'm planning on a blog post/email course/talk/something in the next few…

This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development. Oh come on, you can't tease us like that! You have a duty to satisfy our curiosity now. :) How can hangman with decision theory apply to software development?

Well, I've started on a landing page for an email course. It's pretty rough around the edges, but I suppose I could take this opportunity to solicit feedback. ;)

I would also be thrilled to get my first signup. :)

http://chrisconley.io/delivered/

Post reply on HN