While reading The Toyota Way one of the ideas which stood out for me was the constant mentioning of organisations which picked bits of The Toyota Way, implemented them, achieved some short term gains but then eventually these improvements and went back to the way they were before.

I noticed a similar theme coming out in the series of posts in the last week or so about the decline of agile.

I have worked on several projects over the last couple of years with varying levels of agile being applied. I am aware that agile is considered to be something that you are rather than that you do but for this post agile refers to agile principles and practices.

I have noticed that it is much easier to get working software out the door when we follow these principles and practices but becomes way more difficult as soon as we are unable to follow some of them.

This is a similar idea to one I noticed in The Toyota Way:

One of the common misunderstandings about agile is that writing tests makes us move more slowly and that removing them will allow us to go more quickly. While this may be true in the short term it eventually catches up with us and we can look forward to long sessions with the debugger trying to work out why the code isn’t working as we expected.

A couple of months ago I was considering whether there are any agile practices which are absolutely key to ensuring success. I ran this idea by several colleagues who all pointed out that it was the principles that were absolutely key and not necessarily the practices which are derived from them.

I believe we can therefore make a link between the practices and principles of agile, such that if we don’t believe in thoroughly testing our code, for example, then we are not adhering to the principle of delivering working software or paying continuous attention to technical excellence.

Having said that I have also worked on projects where delivering frequently was not something which the business considered beneficial and we only delivered software at the end of the project. We did take the time to carry out practice deployments more frequently than that to ensure we knew the deployment process but there was no actual deliverable until right at the end, and despite not completely adhering to this principle we were still able to successfully deliver.

As Jeremy Miller points out in his response to the original post:

Life is made much easier if everyone involved into the project buys into the agile or lean approach but even if they don’t it is still possible to find ways to succeed, it just might be a bit more difficult.