Somethings are known before we begin a project, but many things are not. We need to balance our process between decisions that cannot or should not be deferred, and those that it is better to wait on. This episode all about that balance.
You mother probably told you "never put off until tomorrow anything you can do today." Don't procrastinate, in other words.
I once heard Martin Fowler giving a talk at a developer's conference in Colorado. Fowler is famous for his writings on software design, testing, and especially refactoring, and is one of the mavens at Thoughtworks. He is also intensely funny.
He brought up this bromide your mother probably told you (mine certainly did) then said, in his charming British accent "you really should ignore her. Put off everything you can. You will be smarter tomorrow."
It was a funny quip, but also had a lot of wisdom in it. First of all he's right. We get better, more knowledgeable, and gain experience as we live. If you're not smarter today than you were yesterday you're probably doing something wrong. Also, those with whom you work collaboratively are in the same process of improvement as you are and so tomorrow they will be more useful to you as you will be to them. If you are constantly improving your process, which Agile and Lean principles say you must, then you'll also be operating more effectively tomorrow.
But there is another critical aspect of Fowler's statement. Note that he says "you should put off everything you can". This implies that there are things that should not be put off.
I recently did a talk about technical qualities being crucial for agile processes to succeed. Design and code quality really should not be deferred, even with an acknowledgment that Fowler's work on refactoring can help immensely when mistakes are made. But in that talk I also used an analogy that involved flying a plane from Seattle to Miami, to compare the "know everything up front" approach of the waterfall process to the "learn as you go" approach that agility suggests and that Fowler was promoting.
To extend that analogy, we must acknowledge that you cannot learn everything as you fly. There are some critical things that cannot be put off. Among them are:
- How much fuel will you need for the distance involved? (resources)
- Are their mountains, updrafts, or other flights in my path? (risks)
- Where is the jet stream today? (known advantages and disadvantages)
The distance from Seattle to Miami is not going to change. Mountains don't move around either, nor do deserts with their thermal updrafts. The jet stream moves, but meteorologists always know where it is at a given point in time, and we cannot move it.
In other words, there are things we can genuinely know about, and we should not pretend that we don't have the useful information we have.
But most things can change, and change can be very difficult to predict. If you start by asking yourself "what can be put off safely here, and what cannot?" then you're seeking the balance between forces you control and those you don't. When the risk is low you can allow the team be responsive to what they learn, capitalize on the insights and opportunities that come along unexpectedly, and make constant improvements in the way we work.
Of course, this means you need an effective way to assess risks in the first place. I'll address that next time.
Ignore your mother. Well, don't do that in general but realize that agile and lean approaches can sometimes change accepted wisdom in many ways.
(If you're interested in the talk I referred to, it is recorded here -
https://www.projectmanagement.com/videos/843612/enabling-agility--addressing-the-hidden-costs-that-exist-in-every-agile-project)