Of course he’s right. Small changes really do add up, and they really can bring large benefits over time. This whole concept got me thinking, about how I might try to apply the same thing to a typical agile delivery model. What improvements might I look for that could be applied daily and that would continually improve the application delivery lifecycle? Where could I find small adjustments that are easy to understand, even easier to implement and yet  still yield measurable results over time?

There are so many elements to consider. Some are process orientated, some related to tools and yet others that were clearly about people? When I started to get into it, I realised that there wasn’t a simple answer and that like Kaizen itself, I would have to take things in small, discrete quantities, each addressing the various elements of the whole. Delivering working software would be essential to the whole thing obviously, but what are the dependencies and how can they be manipulated for the better?

In the agile delivery world, understandably there are many, many tools and processes across the full stack of any given platform, be they open source or proprietary. I decided that one way forward might be to go back to the agile manifesto and look at the 4 core values. In other words, to examine: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation and responding to change over following a plan.

Would it be relatively straightforward to address each one with a Kaizen mind set? I wasn’t sure, but I thought that I should try to work through it by a process of inductive reasoning. My conclusions wouldn’t be guaranteed, but perhaps more common sense-based. There wouldn’t be a step-by-step guide to agile delivery heaven, but if I realised that if I could manage to change just one, small thing daily, then perhaps I might find myself on the road to agile, cumulative righteousness.

Steven Covey phrases it well when he talks about “sharpening the saw”, [1] . In his book he asks us to apply the habit to ourselves. In doing so, I think that we cannot but help apply it to our lives and our work. To keep the saw sharp is to be at the top of your game, to deliver well using the tools at hand and a winning mind set. As the New Zealand All Blacks say, “ritualise to actualise” [2].

In this 2-part blog, I will address the agile manifesto with a ‘Kaizen’/’sharpen the saw’, mind set. I will look at tools and processes, and the importance of working software. I will examine why people and interactions are at the heart of every successful delivery model and why being able to adapt with minimal fuss is still important for businesses today.

Kaizen and the Agile Manifesto

In this section I’ll aim to develop the concepts of ‘Kaizen’ and ‘sharpening the saw’ and logically extend them to the agile manifesto.

Value 1 – Individuals and interactions over Processes and Tools
In my mind and in practice, individuals and interactions are interweaved. Therefore to ‘sharpen the saw’, we must look to the core of each to properly understand what exactly can be improved. We should work to build upon the following each and every day: trust (individuals and teams); value (your relationships); authenticity (be genuine in your dealings); flexibility (to maintain a healthy work life balance); development (encouraged, recognised and rewarded) and integrity (doing the stuff you said you would do).

Processes and Tools are extremely important and I will cover them separately in Part 2 of the blog, since I believe they warrant a separate section on their own.

Value 2 – Working Software over Comprehensive Documentation
Ensure that the spirit of the team captures the idea of delighting customers each iteration by continually delivering working software and something of value, no matter how small. It’s hard to over-estimate the meaning of this and in my mind extends back to the individuals and interactions part of Value 1. By delivering working code, as an agile team, we accomplish many valuable achievements. We increase team morale, we build trust with our customers and ourselves. We keep our business alive by shipping products that earn revenue. Delivering working software should be a value that is at the heart of every team and we would do well do remind ourselves of that on a regular basis. Working code, means revenue!

Comprehensive documentation can be extremely important, but if we have no working software, it’s pretty pointless. Documentation should definitely not be forgotten and agile is certainly not an excuse to develop code without it.

Value 3 – Customer Collaboration over Contract Negotiation
Much pain has come from awkward or badly negotiated contracts and much of this could have been ameliorated by focusing at least equally on effective customer collaboration. Build and maintain good relationships with customers is at least half the battle of delivering a great product. Like Value 2, Value 3 also harks back to Value 1, individuals and interactions. It’s much easier and productive to collaborate than to negotiate.

Value 4 – Responding to Change over Following a Plan
Plan for change is the best way to think about this. Within teams it is a really good idea to help them understand that adapting to change quickly and with minimal fuss is not only great for efficient delivery, but also for team morale. A happy team is a productive team, is a responsive team.

I am also a firm believer in the tenet that an organisation will eventually or inevitable move into a phase of decline, unless there is a concerted effort to prepare for change; EVEN when sitting on top of a current and very successful peak.

Part 2 of the ‘Kaizen’/’sharpen the saw’ for agile will examine tools and process.