Often when I try to explain Lean and Agile 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:
- Yes - I’m talking about changing the way we work
- No - I’m not talking about working faster (this post)
From http://www.acs.psu.edu/drussell/Asterix/
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
- etc.
From http://loubega33.wordpress.com/
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 realise 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.
Do we have to work faster?
No, if you by faster mean move your fingers faster, think faster … in short, beat the galley drum faster. But I do mean flow the work faster through your process. This can be achieved in a number of things, most feel quite contra-effective at first.
Here are few things that I often come back to:
- Do fewer things at the same time, a.k.a. Limit Work in Process. By doing less things at the same time you make sure that each item is flowing faster through your process. Books has been written about this and I won’t dwell on this here. Besides of moving your work quicker through your process will show you what’s hindering the work to flow, clear up that and your work will flow even faster…
- Engage more people in the work you’re doing. Besides of you doing less work at the same time your team can do less stuff at the same time, minimizing the WIP for your team. Check out mob programming for example.
- Do less of the tedious and repetitive stuff you often end up doing. Take time to automate tasks that is bothering you or take time from your ordinary work. Build scripts is a great basic example. Or stop doing time reports. Or start automating your regression tests. All of these are examples of things that we do to help us move faster.
Conclusion
No, I don’t mean you should move faster or increase your tempo. But I do mean that you should strive to let your work flow faster through your process. And faster still. Through this you will learn a lot about your work and get small pieces completed to your customer, where they can get value from it.