The Agile chain reaction
Some time ago I was doing a presentation for a company about Kanban discussing the benefits of using it and how Kanban can be adapted to their process without modifying anything.
I was discussing the concept of Lead Time and wanted to hear from the atendees if they had an idea of what was the lead time in their current projects. So I asked each of the participants what they thought in turns, and after two or tree answers one of them said something like:
Participant: “But this is Agile! And I worked in an agile project and failed!”
Me: “Well, actually it can be used with any process not only Agile”
Participant: “It doesn’t matter! It smells like Agile!”
So I moved on, but made a mental note, that I had to analyze what had just happened later.
Ponchos and flip flops
When I meet with a client or I’m doing a training that involves discussing Agile concepts my first bit of advice is Never, ever, ever use the word Agile!
Why you ask? Because as soon the word Agile is mentioned it depicts an image of developers wearing ponchos and flip flops riding tauntauns in a crusade to abolish planning, estimates, and budgets while holding a banner that says “Down with Gantt charts!”. And it’s all downhill from there…
What is the trick then? Call it Good practices (or any other positive yet somehow ambiguos term) from now on, and remove that barrier that causes people to recoil and ask for oxygen! Who will be against Good practices after all? Just keep implementing them, having great results and if someone asks you about “Isn’t this Agile?”, just find your most “outraged” face , deny it and move on.
The elephant in the room
However, that is not enough. Agile already left a sour taste in more than one mouth and the feedback I got in my presentation was a clear example of that. What can cause such a reaction?
Similar to any other thought process that we apply when chosing banks, cell phone companies, supermarkets and software, bad experiences will teach us to never try a particular vendor, brand, etc. again. The effect of having experienced a process change setup under an Agile banner and that went really, really bad produces the exact same result.
Agile is not a silver bullet or a pill that you can take in the morning to enlarge your estimation abilities, work better with your team, and improve your results.
Reading a book about Agile is not enough. Doing a training about Agile is not enough.
It is true that you can start by implementing Scrum or using Kanban (or any combination) to improve your planning, communication, transparency etc… and that’s indeed pretty good.
However you will find that there is a bump on the road that is unavoidable. The quality of your code.
Software craftsmanship is the key
Writing code is an art that has to be honed, cared for, and continuosly improved.
Coding is at the heart of most software projects, we can’t forget that or put it aside.
In order to improve our work we need to be craftsmen and make sure that we can generate code with the highest quality possible. Not doing so, will always keep us from embracing a culture of continuos improvement where we deliver on time, on budget, and enjoy what we do once again.
In his Kanban book, David Anderson, as part of his recipe for success he lists in first place to “Focus on quality”. First, not second, not third…
How we become craftmen? Here are some tips:
- Embrace testing in all forms, unit testing, acceptance testing and let TDD and BDD drive your coding
- Practice, practice, practice (Katas, exercises, etc…)
- Participate in events related to your interests and others that may challenge you
- Learn a functional language and apply concepts on your job
- Find a Mentor that can review what you do and “slap” you when necesary
Want to be faster? More accurate? Become better at what you do.