I’m tired. There has been a bunch of fun doing Code Katas but lets face it. It has limited use to you my readers so lets change the pace for a while and do something useful for a change. So lets do a new series. One on the 12 principles of Agile.
One of the biggest things that has changed software development between when I started and now is the implementation of Agile principles into the workflow. In fact one of the biggest issues in my career has been Agile done wrong.
Most developers have never looked at the Agile Manifesto which is shocking since they like to quote their version as gospel. In the spirit of you not being one of those lets dig into the manifesto’s 12 principles.
Because these are straight from the horse’s mouth, know neither Alfred nor I came up with these. If we did, we would not have used so much corporate speak.
Principle 10: Simplicity–the art of maximizing the amount
of work not done–is essential.
Principle 11: The best architectures, requirements, and designs
emerge from self-organizing teams.
Principle 12: At regular intervals, the team reflects on howhttps://agilemanifesto.org/principles.html
to become more effective, then tunes and adjusts
its behavior accordingly.
Why are you doing this series?
As a result of these principle, the developer’s world changed. I want to explore each of these principles and look into what abuses I have seen and instance where I have seen it done well. This should be an interesting series of posts. Ones that I hope will help young developers not fall into the same traps as I did when I was their age.
These 12 principles that Agile on right can make dev work a whole lot easier or it can turn your life into a cigarette smoking monkey in a fez typing Shakespeare all day sort of hell.
Wrapping this up, lets try for the first and a bit less for the second.
Like always leave your questions and comments below.