In the last couple of months I worked hard to get a grip on “what agile really means”. What does it mean for my work as developer and for my surrounding in a company or life?
There are tons of good books, blog posts and articles out there. Don´t expect something really new here, except my personal opinion about that thing. After reading the first and the second book of Vodde and Larman(thx for the great work) I´ve learned a lot but I am still wondering what is so difficult to start an agile transformation.
To be short, here is my opinion:
The main point on this agile thing is to create a system that is “agile”(the verb) and can be easily react on a changing environment. Nothing more. You have to find out for yourself what that mean in your specific context.
The most important things in lean are: continuous improvement and respect for the people. Sounds easy, but IMHO the most people are really struggeling with it.
Agile can lead to more satisfied customers. Agile can lead to better products and happier employees. But agile never promise that to you!
You have to work hard for it and find solutions that work in your context. This implies that there is no “agile is not working here” since it means: “do the best you can in your given context”.
Agile doesn´t mean that you have to adopt XP principles, scrum, kanban or whatever framework you know. Those are just tools which have a really good reputation for applying and living agile principles in the past. But they are just tools which might need to be adapted to your needs. (Nevertheless I totally agree with Uncle Bob that “the agile culture is expressed through a set of practices”. Personally I wouldn´t live in an agile world without XP and scrum. ;-) )
Maybe it´s possible for you to be “agile” without scrum if you find better ways for organizing your work. But the worst thing ever is doing agile (which is wrong anyway, you can just “be” agile) without understanding the true meaning of it. It already has a name: cargo cult adoption.
Please, understand the core agile/lean principles before implementing blindly some tools and blaming the developers if they don´t work.
And, as always, I´m not the first one: Top 10 organizational impediments.