Individuals and interactions over processes and tools. This is the first of the Agile values in the agile manifesto.
So people and the way they interact and communicate is one of the most important things in an Agile project. But do we really value people and interactions over processes and tools ?
A value has only really been adopted if it is reflected in the way we act. In the decisions we make. In what we focus on, and what we continuously are trying to optimize.
Take a look at your own organization. When you talk about improvements, and training what do you focus on ? How do you spend your money for training ? What percentage of your training budget was used to improve people skills, and communication skills in your teams ?
Also, look at what we discuss in the Agile community. There is a lot of detailed discussion about how to do the processes, and which tools to use, and how to use them. We talk about Test Driven Development, Continuous Integration, Roles, Responsibilities – even how to decorate the team room.
But when it comes to people and interactions we are left with a rough framework. We are told what to do – but not how or why it works (or not).
So what does it mean to value people and interaction higher than processes and tools ? Is it enough to install a framework (like scrum), which assigns roles and responsibilities, and leaves room for people to self organize and interact ? – And hope they will figure it out ? Sure, they will self-organize, in fact it seems that we can’t not self-organize (more on this in a later post). – But left on its own, will it be in the most optimal way ?
We are told to pair program. For some, pair programming is the greatest thing that has happened in their career. For others it is a nightmare.
For some teams, having an on-site customer is a great way to build trust, and effective communication between the business and the development team. For others it leads to burn-out (both for the team and the customer!)
We could make empirical studies on the effect of pair programming, on-site customer, etc., and conclude that it works, or doesn’t, depending on who we observe.
There has already been a number of empirical studies – and thats great. We need more facts and numbers on the effects of the agile practices. But instead of just concluding that is good – or bad – depending on the numbers, we need to dig a little deeper. We need to understand not just the ‘what’, but also the ‘how’ and ‘why’, in order to learn, adapt and improve. How do they pair program ? How are they communicating, reacting, thinking, feeling, …. – and why ?
I suggest that we could try to learn more about how the agile work environment effects different personality types. We could spend some of our training budget on letting people learn more about them selves and other personality types. We could spend some more time to train and coach the people on our teams to communicate and interact in the most optimal way, so we do get the most out of the agile promises of self organizing teams, that share knowledge and ideas, and work closely with the customer and the users – to produce the best product in the shortest time.
How does the roles and interactions that the agile frameworks dictate, impact different personality types ? To be a truly excellent team, we need to understand and appreciate individual differences, and different communication styles.
If you want to be successful, it is not enough to have the greatest strategy, the best process and use the newest and coolest tools. If you want a company where the staff are happy, the customers are happy, and you consistently deliver successful projects, you really have to understand human behavior, and understand how to communicate. – Not just the positive messages, but also the tough issues, address the problems, find solutions and move ahead.
If we are going to fulfill the Agile potential, we really need to value people and interactions over processes and tools.