Principles, values, concepts and practices. This is a good reminder of what agility truly is: core principles such as continuous improvement, supported by practices like daily stand up, continuous delivery and TDD.
So why the hell do I see so much teams agile in principle, but absolutely not in practice?
Of course it could be for a lot of reason, but the main one I believe from my (short) experience is that we abuse Scrum and Kanban, which are mainly about management practices. We let people believe that agility in software development is only about index cards on a wall.
Worse: we let them think that be agile is an easy thing.
Apply Kanban practices, such as flow management and limit work in progress, is not really hard. Apply Scrum practices like daily stand up, retrospective and sprints could be a little harder. But still, this is nothing but some change in management practices.
It looks huge, but you can do it without changing your mindset. You can easily follow Scrum practices by creating successive little waterfall project instead of a big one (I agree, it is already an improvement).
Why are Scrum and Kanban so well accepted? I believe it’s because it can be understand by:
– Less detailed specification
– More deliveries
– The right to change your mind and priorities during the creation of the software
And yes, this is an easy thing to sell to managers.
A few months ago I have this discussion with a manager:
“Why do you ask the team to release every week, when you see that it takes half a day to package each release, and that we have regression each time?
– Because this is agility right? Deliver often!” 
The only way I know to be agile in software development, is to be able to improve your code continuously. To do that, you need to be really confident about any change you do in your codebase, because you don’t want any regression. This is why unit testing, pair programming and TDD are so important.
By the way, these practices are first class citizen in XP, which is an agile method as well. But obviously, it is easier to sell Scrum than XP to managers.
TDD is a technical agile practice. Like continuous integration or pair programming. These practices will improve your life, as a developer, much more than daily stand up, you can trust me.
Thus, this is your responsibility as a professional developer to know and use these kind of practices, at least when you pretend to be agile. Actually it will improve your life even on a non-agile project, but this is another story.
And if you are an agile evangelist, please do not forget to learn and talk about these fundamental technical practices.
I realized a few weeks ago, reading the excellent Software Craftsmanship by Sandro Mancuso, that I am not the only one to feel this problem. What I did not understand before reading this book is that the whole Software Craftsmanship movement is partly born because of this lack of consideration for technical practices. Software Craftsmanship is, beside other things, the technical part of agile methods.
This probably explains why I feel so close of this movement since the very first time I heard about it.
Almost the same people that created the agile manifesto have been feeling the need for another manifesto, insisting on the importance of technical excellence.
As Sandro explains, all the successful software did not have an excellent codebase, but having a bad codebase is definitely one of the main reason for failure (and also for developers burnout by the way).
Yes, be agile means better client satisfaction with better product. And guess what? This is fucking hard to achieve! So you won’t be able to do it if you are not interested in the technical practices allowing to produce great software.
I know what you think: “I am interested but I do not know where to start!”
The good news is that Sandro Mancuso himself propose a public training in Lyon next 14th-15th september. Don’t miss the chance to learn with one of the leader of the Software Craftsmanship Community. Find it’s a bit expensive? Get a 40% discount with the code “I_WANT_TO_CRAFT” !
Thanks to Frédéric James for the kind review.
Effectivement, la plupart des formations agiles insistent sur le rôle du PO et sur les artefacts liés à la méthodologie, mais assez peu d’informations sont diffusées sur comment bien organiser l’équipe de développement.
Pourtant, le manifeste agile indique clairement que « une attention constante à l’excellence technique et à la qualité de la conception améliore l’agilité », mais cette règle peut rapidement se retrouver noyée par une mauvaise interprétation de celle-ci : « Les meilleures architectures, spécifications et conceptions sont issues d’équipes auto-organisées » cette dernière insinuant que c’est le boulot des développeurs de se débrouiller avec la technique, sans définir un cadre clair sur quoi faire pour que cette technique soit en adéquation avec l’agilité !
Donc je suis bien d’accord avec cet article. L’important pour qu’un projet soit vraiment agile, c’est qu’il doit être dans la capacité technique à accueillir favorablement le changement, et croyez moi c’est très loin d’être si simple ! ! !