We are just a few days after the amazing experience that was ALE 2013. I enjoyed being for three days in a large family of European Agile and Lean practitioners, and I learned a lot from the conference. I’ve seen many enthusiastic blog posts after the event, and I’m glad that it was so much learning happened.
But this blog post will not be another one praising the experience. Instead, it will be about this: we’ve done it, it was great, how can we make it awesome?
I haven’t yet gathered all my thoughts after the conference, but there is one that keeps following me. A few speakers presented models to the audience; Jurgen talked about the learning model, Vasco talked about a model without estimates and I talked about a model for incremental design. There were many others which I didn’t mention because I don’t remember them now.
Having models is excellent. It shows that agile and lean thinking is evolving and maturing. It’s the same thing that happened with our understanding of the Solar System and then of the Universe, or of the way the matter is structured. But I couldn’t shake the feeling that all these models (yes, including my own) lacked something. And that something is boundaries. Continue reading “Raising the Bar for Models in the Agile/Lean Community”
In early 1990s, one former US AirForce pilot became Chief Engineer of a software company. The teams he was working with had many troubles while developing a product. Trying to fix the issues, he decided to fundamentally change their workflow. In 1995 he introduced his new method to the world under the name of Scrum. Today, software teams adopting it often focus on one thing: how to do Scrum by the book.
I can only imagine how the world would have evolved if we treated hammers in the same way. Someone needed to bind two pieces of wood together, thought of nails and used a piece of metal to drive them. He shows his method to other people, they all use it and they call it “hammer”. The 3rd annual convention on the topic focuses on making hammers too light to drive nails anymore.
It doesn’t mean that design patterns are bad, Scrum is useless and hammers aren’t helpful. Just that we tend to forget the purpose and focus on the method.
Customer / Product Owner / Manager / Fellow Developer comes to you with an article about “The New Best Thing” that “Solves All Problems that You Never Knew You Had” and praises that technology until you are forced to take it into account for the current or future projects.
I found in such situations that the praised technology is seldom useful. I never trust marketing materials published by the creator of that technology – be it a large company, a small company or an open source project. I never trust the fans of that technology. I don’t trust myself (at least I try not to, since I want to be an skeptical empiricist). The only thing I trust is tangible proof.
Since TDD gained exposure in the industry, lots of people ask:
Does TDD really work?
This is a perfectly valid question and many TDD-ers I know tend to avoid it, probably because they don’t know or because they fear the answer. TDD is wonderful at personal level; it makes you feel very good about yourself because of the continuous reward system that’s ingrained in the practice. It’s hard to let it go.
But does it really work?
I think this isn’t the correct question. I think that we should ask: