The undocumented agile practice

Many books are written about practices that help teams produce better software. No doubt many of you immediately think about pair programming, test driven development, retrospectives, planning and estimating, continual integration and many many more. I'm sure that a lot more can be written about these and other agile practices that hasn't been written before, related techniques that are applicable in a specific context, ideas that live in the heads of practitioners and coaches. Lots already has been written though, if not in a book, then surely in a blog post or scattered around Twitter or a plethora of other social media. But let's face it, however much is written about a specific practice, there will always be a situation that has not been described, a context in which the handbook practice doesn't just work.

However much we can disagree on the reasons why Brazil lost the soccer world cup quarter finals against the Dutch, I'm sure most of you will agree that it takes more than 11 skilled individuals to beat a gelled team, especially since qualification ensures the teams in the world cup finals are all good, to say the least. All teams study and memorize systems to setup an attack and score. But the opponent can - and will - change the environment in which the system was taught. If the team is not aligned, understands the philosophy behind the system and acts as one, it will not be able to adapt and tactics might fall apart.

The same is true for agile teams. However good the individuals are, if a team doesn't work as one towards the same goal, it misses out on a lot of productivity, quality and fun! Strong committed teams are the foundation of every successful implementation, agile or otherwise. Yet, not an awful lot is written or told about how we form these teams. We somehow trust they are just there.

The diversity in context and specificity of the challenges teams face, requires a strong foundation, a powerful committed and aligned team to benefit fully from the techniques they were taught. That is why I believe that the practices mentioned above merely come second. Sure, they help teams to reduce bugs in the software. Sure, they slowly increase the collaboration and result in better team work. Sure, they increase visibility and therefor make it harder for process failures or inefficiencies to remain unnoticed. But for them to be really successful, for them to reach their full potential quicker, we better start communicating - and learning - how to build these teams.

Yet, most agile literature, most discussions are all about the methodologies, about what's best: Scrum or Kanban, about what's next, about the processes and tools of the agile community. Are we forgetting the very first statement of the Agile Manifesto: "People and interactions over processes and tools"?

Imagine

Imagine an island with no roads, no infrastructure for our western luxury, and people who do what they have been doing for a long time. Sure, they have challenges, but they get by. One of those challenges is transportation, going from one place to another to find food and visit neighbouring tribes. What would happen if we would give each and every one of them a car - of course including the manual, even translated in their own local language -, would sit by their side while they started the engine and drove the first 100 meters along the pebbly beach, and would leave?
I personally can think of only two situations... Hopefully they get stuck in the sand just a few kilometres further down the beach and abandon the car right there. Hopefully they shout out some “wookoolooloo” - lucky us we don’t understand which curse we’re awaiting - and forever call us the stupid species. But some might be fooled by the respect for alien intelligence, the shiny coating on the brand new car and the promises of a better life, if they only tried hard enough. Some might be tricked into trying harder and, if that doesn’t work, even harder. Dangerous! That’s what it would be! Bloody dangerous, literally! No doubt someone would try to pull the car out of the sand and be hit in the face by it. And someone else would sooner or later realize that cars and cliffs don’t make good companions. But let’s hope that they would run out of petrol soon and not cause too much damage.
If we know all this, if we know the inevitable future in this story, why would we ever give cars to those people without properly guiding them or making sure the right infrastructure is in place? Why would we ever risk endangering them, while we only want to improve their means of transportation? Why would we, when we would come back later, take their food away if they wouldn’t use the cars exactly the way we showed them?

Let cars be processes, let roads be tools and for the sake of simplicity, let people be people. Why is it that I have seen this happening so many times in large enterprises?