Yes you need a plan, yes you need to document.

I recently took a decision to publish daily because I believe that doing so will enable me to start small, fail small and eventually someday through compounding effect, what started small will eventually be big. The reason I mention this is because the commitment has made me realise I need a plan. As much as I consider myself agile and flexible, there are times when I just don’t have the words to say or write or don’t feel like delivering or releasing any of my work and during those times it helps to have a plan.

In this post I am going to touch on two values from the agile manifesto which in my opinion seem to be the most misinterpreted.


If you are reading this you probably know that I am a software engineer by profession, if not now you know. One of the arguments I constantly hear within my industry is what’s agile software development and whats fake agile software development. Now I could probably point people to the agile manifesto or a few of Martin Fowler’s articles but then I’d have nothing to write about. So this is my take on the argument.

Working software over comprehensive documentation

I’ve heard people interpret this as if there are unit tests no other documentation is needed. Which always makes me cringe because firstly how do you even run the unit tests if there’s no documentation.

Yes, I understand that the argument can be made that you can read the tests and understand what’s happening in the code but I believe it shouldn’t be the only documentation. There are other areas that tests cannot cover such as the architecture of the project, configurations, etc.

Working software over comprehensive documentation does not imply that there should be no documentation at all, it just means the focus should be working software not that we should neglect to have any documentation.

Responding to change over following a plan

On this one I am going to simply put like this, you need a plan, having no plan is the quickest way to get nowhere. What this suggests is that you need to be flexible in your thinking and not just do things because the plan says so. If certain variables have changed this may mean that you have to change your plan in order to respond to that change and it’s ok to do so.


Not having documentation will make it difficult for anyone new joining the team to fully understand the codebase. Automated tests alone are not enough to document your project. Having no plan is not a good idea.