Over the last 15 years in software development a movement that actively seeks to curb this has been gathering steam: Agile Software Development.
What is this Agile you speak of?
Agile was introduced as a means to deliver working software to end-users faster and with closer alignment to their needs. Despite the technology flavour of the Agile Manifesto, I believe its success is largely based in encouraging a culture of interaction and a sense of purpose among groups of people.
This movement is of particular interest to me for a number of reasons, not least of which being that it aims to cut waste and deliver meaningful value to the customer. Focusing on the human element of the software development process has contributed significantly to its success. For many years, software development was seen as an engineering practice where rigid process was intended to add to the predictability of the result. Requirements and priority changes are difficult to predict with certainty. It can be both restrictive and wasteful to take the view that rigid process and detailed planning upfront enable predictability and support customer satisfaction. Agile supports the principles of team cohesiveness, collaboration and delivery, and the acknowledgement of the humanity inherent in teams is central to its widespread acceptance by managers and workers alike.
To understand how and why this has been the case, we need to unpack the people side of the work environment. Motivation is something that falls neatly into that category.
What motivates you?
Motivation is a tricky subject and has been the basis of much theoretical and empirical debate. Part of the reason it is such a hotly discussed topic is that it is critical to the success of any endeavour where people are involved. Furthermore, people are motivated by different things. Many models and schools of thought fail to acknowledge this and try a one-size fits all approach that will show success for certain groups or individuals, but not others.
On a personal level, and in in my experience, some of the worst motivators are the “hard” ones, which are too often the first port of call for managers. These include both the stick and the carrot – KPI’s, bonuses, etc. I believe these are chosen because they are easy to put in place and because managers were managed like this themselves. My experience is that, while they may be quicker to put in place, too often the effort involved in revisiting these, as well as the correlating decrease in autonomy, makes them effective only to a point. Furthermore, unless the measure is very cleverly constructed, success is often met with a false ceiling of the measure itself. Don’t get me wrong – I like a good bonus as much as anyone, but the time frame in which this can be effective as a motivator in the absence of genuine motivators is limited. David Rock developed the SCARF model that covers what he believes are the key motivators of individuals:
- Status is about relative importance to others.
- Certainty concerns being able to predict the future.
- Autonomy provides a sense of control over events.
- Relatedness is a sense of safety with others - of friend rather than foe.
- Fairness is a perception of fair exchanges between people.
© David Rock, SCARF360
The central principle of the model (and the field of neuroscience generally) is that humans are inherently social beings and therefore, the essence of what makes a conducive work environment is social in nature. Simon Sinek builds on this nicely, “The most basic human desire is to feel like you belong. Fitting in is important.” I like this model for a number of reasons, not least of which is that it humanizes the team and acknowledges uniqueness. It forces a manager (or a teammate) to get to know his team. This is critical, and the team that first sat down to put the Agile Manifesto together had clearly seen its importance.
Related Article: Is Agile Common Sense?
How does Agile support this?
The Agile Manifesto is simply a set of four values with 12 supporting principles. How can something so basic have caused so much debate and spurred such a powerful movement in arguably the most emergent profession in the world? Many maintain its power comes from its ability to capture succinctly extreme complexity in a very simple construct.
The first of the manifesto’s values is revealing: “Individuals and interactions over processes and tools.” This is not to say that Agile is devoid of tools, but it values Individuals and Interactions more than Processes and Tools. Agile, as a movement, is purposefully process-agnostic. There are a number of processes or methods that claim to be founded in Agile thinking, but many of these forget their origins, or during the implementation start to focus more on process and tools. I encourage my teams to go back to first principles (pun intended) and understand what’s driving how they’re working. If a team is fundamentally moving away from the values and principles, they should re-evaluate some of the choices they’ve made. This focus on individuals and interactions positively drives relatedness, fairness and autonomy.
Even in this Agile context, I find people get stuck in the process. I recognize there will always be certain requirements that cannot be avoided. What is a little ironic is that, all too often, we are happy to fall back on the process crutch and, too quickly, we avoid human interactions. Again, ironically, the industry that gave rise to the change in thinking supports the bad behaviours.
As an example, I believe email can be the hero, or the villain, in teams. How often are round-robin emails seeking feedback completely ineffective, in many cases necessitating a follow-up discussion or worse, a meeting with a broad group (who are likely unprepared)? All too often everyone who needs to provide input is within spitting distance of each other and those who aren’t often shouldn’t be involved or add little value anyway. Why then did the conversations not happen? Were people too busy with meetings and email because other people were unable to have direct conversations? What happened to people working with people?
When evaluating your team (or yourself) or when transitioning to a more team-based and Agile approach, you should watch out for some of these common traps / learned behaviours:
- Abdicating responsibility – this is so common in current organizations it is scary. Think about “I am waiting for so-and-so. I sent her an email last week.” If you are dependent on someone, you need to ensure the outcome is reached and that you negotiate effectively. Think about it – how condescending is it to tell someone that you need something from them and when you need it by. Surely there is still give and take in the world?
- Busy-ness over productiveness – think about how much time you spend rummaging through meaningless emails and communications. I am not saying you should not go through your email, but you need to learn to prioritise in the context of your team’s goals. There are also efficiencies to be gained by dealing with things differently, for example, set aside dedicated slots to answer emails rather allowing it to distract you every time something flutters into your mailbox. Find something that works for you and be disciplined.
- Valuing oneself more than the team – organizations love a hero but teams don’t. It’s counterproductive to team effectiveness. Everyone needs to pull their own weight and do what is required to show the team as the hero.
While my thought process has been led by my experiences with Agile Software Development thinking, my view is that the themes and lessons are universal and can easily apply in any context. At the end of it all, people are social beings and are motivated by social things. Should we not then have direct interactions with other people? After all, are these interactions not what drive relatedness and ultimately make us human?