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?
February 20, 2013 at 8:51 am
I’m not looking to change your mind, I think you are spot on.
If you practice agile (and more specifically scrum), you should be doing requirements workshops and you should be creating a story board (aka backlog). It is during the process that you should also be identifying critical path, as well as any overly complicated pieces of the system. Nailing down the critical path, which is usually the foundation, can be done with rapid prototyping, but it should definitely be thought through when thinking about the requirements. Furthermore, rapid prototyping should NOT be an excuse to not use good development practices, like loose coupling, high cohesion, DRY, etc…
I agree 100% that rapid prototyping should not be an excuse to avoid making big foundation and architecture decisions up front. I think the thing that hurts people the most is that they start building the interface first without thinking about how the different parts of the system will interact with each other. They end up avoiding the more complex (and therefore riskier) parts of the system until too late in the project and end up having to make too many compromises, and therefore incurring too much technical debt on too many critical parts of the system.
Lastly, there’s nothing that says that you can’t rapidly prototype your API first, and then build the underlying functionality. You still have to think through what you are building from a high level.
February 20, 2013 at 1:30 pm
Awesome reply Brian! I particularly find that this resonates with me:
I think the thing that hurts people the most is that they start building the interface first without thinking about how the different parts of the system will interact with each other. They end up avoiding the more complex (and therefore riskier) parts of the system until too late in the project and end up having to make too many compromises, and therefore incurring too much technical debt on too many critical parts of the system.