Should Life Be an Agile Project?

There are some situations in which jumping in with both feet is just fun. And sometimes that’s the right approach. But it is fool hardy to take the “hold my beer” approach to everything. Thinking through a few different scenarios, the reasons for a more cautious approach become obvious.  

Repercussions vary from “Hadn’t ought’a done that!” moments to personal or financial ruin.  

In my work with, and study of, tech startups I find that, far too often, dangerous assumptions are made early on. The primary assumption being: “the thing we’re going to build is needed and wanted by this or that industry or group of users”.  

With inadequate advance market testing, prospect interviews or research, the founders too often make a vague plan, assemble a team and go. Some quite accurately call this “ready, fire, aim”. Weeks or months later the “thing” - product or service is “ready for market”.  

Only now begins the testing that, in my view, should have been done before the first line of code was written or engineering diagram was drawn. If the founders are made of money, or it’s a hobby project, or the stakes are low for any other reason, this may be just a fun experiment. 

If none of those are true, they might just be in for a very rude awakening. 

In a world where so many tools are within our grasp, I am stunned at the near non-existence of this type of research testing. They are so often done only after massive resources have already been expended. 

If the instincts were correct and the assumptions were spot on, the project may be a great success on the first go. Personally, I have not seen this happen – ever. 

Agile methodology is popular, and many teams profess to follow it. Short “sprints” of creation, regular validation, pivots as indicated by the validation. 

Sadly, this is often just lip service. And that is costly. 

Personally, I aspire to approach all my own projects, whether business, consulting, physical building, or any other, with more advance testing and challenging my assumptions. 

As for me, I fail – a lot – to do enough of this. But I suppose that too is part of the same process. 

I’d like to remember that the higher the stakes, the higher the priority to “plan, do, adjust, – rinse and repeat”.  Any project can include a “Minimum Viable Product” – IF – I exercise the patience to do it.