This principle is much like the one previous about sustainable development. Agile doesn’t ask us to shortcut quality and increase technical debt in an effort to deliver software faster. It is precisely because we do not shortcut quality and incur technical debt that we are able to move faster.
I have worked with many teams to introduce Behavior Driven Development (BDD) because, among a great number of other advantages, BDD allows developers an easier way to access the practice of Test Driven Development (TDD). And, in my experience, TDD is the only way I have seen out of the practice of “Big Up Front Design”.
Not sure where I first heard the phrase “you can’t inspect quality into a product” but I have certainly used the phrase myself all too often in my consulting gigs. After a quick Google search, I found the originator of the quote was Harold Dodge and it was first used in a manufacturing context. While I generally eschew appropriating manufacturing analogies for comparison to software development, in this case, it is certainly apt.
Back in January I stressed the need to come up with some new metaphors regarding software development because our old metaphors were causing some problems. I still believe this to be true more than ever. Developers are not just cogs, but are individuals. Research has shown that the most productive developers are up to 10 times more productive than others (see Peopleware for more). You cannot just plug any developer into a product team and expect them to perform at the average level for that team. Domain knowledge counts as well.
However, one thing that I did not do a great job of was suggesting a replacement metaphor. The one I used was the film industry. While I was correct that development is a creative art, it has recently been pointed out to me that making motion pictures usually takes a great deal of upfront planning and design – not a good analogy for an Agile advocate. This misstatement showed that I knew less about the film industry than I do software development.
Continue reading Software Development is Like 30 Rock – A New Software Development Metaphor Part 2
I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.
While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.
Continue reading Agile = Antifragile Part 2
I spend a good deal of time trying to make myself a better Scrum Master (see blog). This means reading lots of books, a great deal of googling and reading many blogs. Recently I ran into one called Coding Horror by Jeff Atwood.
He had a great entry about Discipline in software development.
I had the same conversation with a colleague of mine years ago when I was first introduced to Agile development. My argument went something like this. Left to their own devices, software developers are a fairly undisciplined lot. Every methodology of the last 40 years or so are merely a response from management to attempt to bring some order and discipline to software developers (and by extension software development). I joked with him that I should come up with the next fad, called disciplined development, throw a few buzzwords and ceremonies into it and then I could make a killing as a consultant. I mean isn’t that what every methodology fad has been so far?
Continue reading It's the Discipline Stupid