Last week I attended my first Lean Coffee here in my new city, Seattle. It was a great experience that I look forward to going to again. In fact, I suggest that everyone look for a Lean Coffee in their area, or create one!
At this Lean Coffee I was challenged, albeit nicely, on my desire for my development team to do more thinking before execution and creating more design documents. In fact, I’m strongly encouraging it in my team. The premise to the challenge is that this felt more waterfall than agile. That, maybe it is preferred to do a rapid prototype approach with a higher acceptance of risk.
I completely agree with the agile principle that there is a flaw in with a waterfall style execution. Waterfall pretends that everyone finds, despite what you will learn throughout the execution phase of a project, that they were master psychics and have flawlessly predicted the best outcome for their deliverable. Complete hogwash, as they say in the South – from which I hailed until a few months ago.
However, until further enlightened, I will continue to believe that there is value in thinking things through to completion. The question is that of scale. You don’t have to plot your course over the entire mountain but, for each leg, plan your journey and understand the choices you’re making. I have coached many an employee in this way because there is significantly less waste and a much leaner process when you get things the basics right the first time. As a manager, I don’t want to see my team constantly getting 90% through a story or task and finding they were building on top of design flaws simply because we dove right into the work and didn’t take time to consider what we were going to do in the first place. I think that is one of the worst kinds of waste. It is also one of the most avoidable. I also find that, while people can and do learn from mistakes, often people learn faster from doing it right and practicing what made it right over and over again. As I learned while getting my music degree, practice doesn’t make perfect, it makes permanent.
Rapid prototyping has its place and can be a very good tool in the right circumstances. It’s just not a buzz word we should throw out to keep our developers from having to think something through. So, for now, my team will keep measuring twice and cutting once when the situation calls for it and we’ll inspect and adapt and go from there. I can’t believe how many times I find that it all points to the old saying being true: everything you need to know you learned in Kindergarten (or at least in elementary school).
As always, I am eager to hear your thoughts on the subject. Can you change my mind? Do you want to?