Often when I try to explain Lean and Agile and there’s a couple of things that I fail to communicate clearly. Quite shortly these things can be summed up with these two short answers:
This post is about me failing to communicate that I we shouldn’t be going faster, work quicker, beating the drum on the galley with a higher frequency. No - there’s something else.
Much of the things I try to help teams and individuals when I introduce them to lean and agile has to do with moving faster:
- faster, smoother flow
- shorter iterations
- faster feedback loops
After stating a few of those I often feel a bit stress and short of breath myself. Sometimes I stop and think, right in the middle of presentations sometimes; is this really correct? Should I come out like the guy talking about faster, faster, faster? Isn’t this exactly what the Ford-dudes talked about in the early years of this century?
All of this is summed up with an excellent question, from my colleague and friend @anderslowenborg;
Why does it have to go so fast all the time?
After really thinking long and hard about this I have come to realised that it really should flow faster, as fast as possible in fact. But not faster… let’s come back to that last part and instead try to answer the question in the heading of this section.
There’s many reasons to strive to a faster flow, faster process but here are a few that I come back to:
- with a shorter feedback loop we will learn about our product faster. This is the foundational thinking behind continuous delivery and lean startup; get things out there as fast as possible and learn from how it behaves, is received and how your users end up using the feature. We can, quite simply, validate our hypothesis about our product more frequently and hence get more frequent opportunities to make corrective actions.
- with a faster flow we will learn things faster about our process faster. Remember the last post? Where I called agile methods problem finders? We want to find those improvement opportunities as fast as possible. The faster we get to know them the faster we can improve. A process with little work in process, and hence a fast flow of the work, will reveal these opportunities faster.
- with a faster turnaround of features, we will build trust with our stakeholders. If we can put a little something into production every day, I guarantee that you will see less and less demands for estimates, plans and (the wrong kind of) commitments.
- completing (smaller) stuff often is more fun and more engaging. You, and your team, will feel more in control over your destiny and that what you’re doing is important.
As fast as possible - but not faster
Ok - so we want to move fast. Yes… but not too fast. One way to go faster is to be sloppy and skip stuff that takes time, testing for example. But that’s not what I’m talking about.
First - we want to keep a sustainable pace, a tempo that you can keep week in and week out. This is not a sprint (how’s that for a bad name of an iteration, Scrum…) it’s a marathon.
Secondly - we want to keep a tempo that doesn’t hurts our quality. What happens when code quality goes down? It takes more time to code new features, because you have to work around a lot of stuff, jump through hoops etc.
Keeping a tempo in which we take the code quality into consideration, keeping the code clean and doing refactorings as we see needed, will ensure that we can keep the tempo up.
Yes, it’s a self-enforcing loop.