The first post in this three-part series began by stating my thoughts on the principles behind getting done. If we think about how we deliver value and what customers of our products care about, we have to wonder what our customers would say if they could observe our day-to-day activity. Would they be happy with our progress and the activity we choose to do in order to get done? This second post in the series picks up where I left off and dives right in to more principles to ponder.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t, and do it.
Give yourself permission to start. Give yourself permission to experiment. Give your intuition some credit. Give yourself permission to explore what you don’t know and play so that you discover what you don’t know and then get on to the other stuff you don’t know by experimenting. You know how to start something right? So just start, which leads to…
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
When I coach teams, I tell them that if they spend more than a week trying to figure something out they are wasting their time and the time of the business. Figure stuff out by doing stuff in small experiments: Build and experiment. If you allow other stuff to get in the way, then the thing you were working on must not have been that interesting or important. Move on to a variant of the thing so that you actually get some value created, which really is the purpose of done … value creation.
I “love coach” friends to look at what people value by observing where they spend their time and money. If it is not spent on you, then it is time to find someone else that does spend time and money on you. It is the same with software products: Spend the most time and money on the stuff that matters most and get it done. Be nice to the feature you don’t like by just dumping it.
6. The point of being done is not to finish but to get other things done.
The point is to create value. The faster we can get one thing done the faster we can get “done done” with other stuff. I coach teams on a pet phrase: “Stop starting and Start finishing”. If you have too many things in process, then nothing is getting done. You might look busy but guess what? You are not providing value until you get stuff done, and you are not effective until you can move on to get more stuff done … so get it done.
7. Once you’re done you can throw it away.
Sure you take pride in creating stuff, I certainly did when I was creating solutions (especially at a startup). But once created, then what? You move on to the next. At some point, the stuff you created will need to be changed. Or it gets thrown away, because requirements have changed. You are not going to get it perfect and you are going to throw it away and build the next version at some point which leads to…
8. Laugh at perfection. It’s boring and keeps you from being done.
It means let the thing go, validate it, move on. Revisit it later when you have more information or have to adjust to something learned. This does not mean you abdicate quality!!! A saying I like is “The perfect is the enemy of the good”. Perfection slows us down and causes us to second guess and create blame. Perfection holds us back from making progress, from getting it in the hands of customers in order to validate what we created.
9. People without dirty hands are wrong. Doing something makes you right.
In lean thinking we are urged to “go to the gemba”, which means go to the people doing the work because they know best how to change HOW we work. Design is not development. Get your hands dirty by doing something.
I want to point out another aspect of this when it comes to “middle management” and I will write another blog on that alone. In Agile, middle management has the super-important role of creating the best possible environment for development, a role that should not be taken lightly. Apply lean principles to help the team succeed by getting your hands dirty. Improving the HOW of how teams deliver.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.