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"?
I can't speak for Agile literature, but people and interactions are often forgotten elsewhere, or get minimal visibility.
ReplyDeleteIt seems to be like air: we all need it and so take it for granted without exploring it, studying it, learning about it.
So we assume people interaction, management principles, communication basics - to our peril.
Cheers, Paul