PurelyFunctional.tv Newsletter 302: The Agile Software Factory
This week, I've been really digging into Agile. I've worked in Agile environments at a few different companies and I'm still trying to digest the experience. In short, I'm not a fan. I want to put together some cogent descriptions of why I don't like them.
I've put together a bunch of resources mostly deconstructing Agile, or at least giving a different perspective on it. Agile is kind of the air we breathe these days, so it's hard to even recognize the hidden assumptions involved in the Agile perspective. I hope these resources can help you see it from the outside.
Please enjoy the issue!
PS Want to get this in your email? Subscribe!
Clojure/conj is happening this week. Please don't forget to say thanks to the folks at Cognitect who make working in Clojure possible. Clojure is freely given to the world with nothing expected in return. Saying "thanks" is the least we can do when we see Rich, Stu, Alex, or the many other people that make Clojure. I'm sure they would appreciate it. If you can, a small gift would go a long way.
I will be speaking at IN/Clojure in January. Be sure to get your tickets while they last.
The classic text.
Catherine Swetel talks about different way to measure the output of your dev team. How can you optimize if you don't measure?
Erik Meijer talks about why Agile is a cancer on the software development industry.
Mirco Hering talks about the problems with the factory metaphor of software development teams.
The Secret Assumption of Agile YouTube
Fred George explains the programming skills that were assumed knowledge in the Kent Beck-style agile world.
Agile is Dead YouTube
Pragmatic Dave Thomas gives a brief history of Agile and blames the Agile industry (coaches, training, etc.) for turning it into something it was never meant to be. I can't say that it's inaccurate.
But he then gives a pretty milquetoast replacement of Agile called "Agility" and defines it as a hillclimbing algorithm to incrementally approach a goal in small steps. While this isn't a terrible approach, the explanation does little to help teams struggling to make improvements.
Jeff Atwood thinks about whether manufacturing is a good metaphor for development.