Agile is built on many ideas (Kaizan, Lean, Kanban, etc.), but one of the most important is a body of research into human motivation. This article explores some of these ideas and highlights how it is very easy to adopt Agile but miss out on these motivational factors
I often ask organisations why they want to adopt Agile and the answers all boil down to wanting to increase productivity. They may say they want to reduce operating costs, get projects done more quickly, reduce product time to market, or just that as everyone else is doing it. They don’t want to get left behind. Essentially it is productivity.
Indeed, the title of one of the key Scrum Texts, Jeff Sutherland’s “The Art of Doing Twice the Work in Half the Time” (2014), suggests a 400% productivity increase (the back cover states “400 – 800%”). This sets pretty high expectations.
Another question I often ask organisations is why they think doing Agile will increase their productivity. This is where the conversation often falls flat. I have seen many companies getting very enthusiastic about the nuts and bolts of Agile–Daily Stand-ups, Sprints, User Stories, etc.–without really questioning why doing these things will lead to a massive productivity hike.
The Scrum Guide teaches us what to do but not why. One of the many reasons why it makes sense to adopt Agile is because it harnesses human motivation and draws on motivational theories dating back to the 1940s.
Abraham Maslow and Motivation
Maslow is often considered the founding father of these motivation theories, and his Pyramid of Human Needs is very well known:
The theory states that humans will sort out their survival (physiological) needs first (food, water, warmth, shelter) and then turn their attention to securing these needs. Only then would they go on to explore the higher levels of the pyramid–a sense of group belonging, a feeling of esteem, and realising their full potential.
Maslow, writing in the 1940s, believed that most organisations motivated their employees by focusing only on the bottom two levels of the pyramid by providing for their survival and security needs with salaries, bonuses, health care, pensions, etc. He argued that managers could better motivate their staff by embracing all levels of the pyramid.
Motivation Through Agile Teams
So how does Agile address the higher levels of the pyramid? The answer is through the Agile concept of teams. Teams in Agile are self-organising and self-managing, “they internally decide who does what, when and how” (Scrum Guide). This autonomy brings with it a sense of belonging.
Agile teams are also cross-functional. An Agile team could easily contain designers, architects, business analysts, developers, and testers. Each team member is critical to the building of something valuable in each sprint. Each team member can, therefore, enjoy a feeling of esteem, knowing that their skills, creativity, and dynamism are playing a critical role in getting the project done.
Compare this to companies who organise themselves into analysis teams, testing teams, coding teams, etc. In such a structure, the developers may be be coding for a product they don’t really understand while the testers are chugging through test cases without feeling any sense of working towards a goal.
The Agile team has a sense of purpose and achievement; team members can take a pride in working together to build something of value. Each team member has the knowledge that their skills are critical to the creation of value.
Douglas McGregor – X and Y Theories
McGregor, a student of Maslow, further developed motivational theory. He proposed that management styles tend to conform to either Theory X or Theory Y.
Theory X is built on the supposition that people are inherently lazy and are only at work to get paid. Thus, managers have to constantly push their team members to avoid them slackening off. Reward and punishment strategies are often used to push employees to achieve the given goals. X Theory management is centered on control.
Theory Y, however, is built on the supposition that employees can find fulfilment in their work and that work is a natural human activity. So, a Y-theory manager has to set up a framework where individuals can work to achieve the goals set out. They display trust in their staff and empower them to work autonomously.
Given everything we know about Agile, it is hard to align it with Theory X. We know that Agile teams are self-managing; they are empowered to make important decisions about how to do the work. We know the values of Scrum are commitment, focus, openness, respect, and courage. We know that Scrum Masters are Servant-Leaders. They are not Project Managers, and they do not assign action items to team members.
Obviously, Agile is aligned to the Y Theory of human motivation.
Daniel Pink – Autonomy, Mastery, and Purpose
Pink’s motivational theory can be summed up in two sentences: “Larger rewards lead to poorer performance,” and, “The real motivators are autonomy, mastery, and purpose.”
In his TED talk of 2009, Pink talks about various experiments which have falsified the idea that if you reward people with financial motivators, they will work better and faster. In fact, the experiments have suggested the opposite, that financial rewards make people work more slowly because they stifle human creativity. (There is an exception in that financial rewards may work for repetitive, mechanical tasks that require little thought or creativity).
His three motivating factors fit well with the Agile framework.
- Autonomy: As mentioned above, Scrum teams are self-managing and are empowered to make crucial decision on how to get the work done.
- Mastery: The Scrum team is cross-functional and multi-skilled. Each member of the team has skills that are critical to creating something of value every sprint. Every team member has to be a master or a subject matter expert.
- Purpose: Sutherland talks about great teams as being “transcendent.” In other words, they have a purpose to achieve something extraordinary, something that transcends their own horizons.
Other researchers (such as Herzberg, Ryan & Deci, and McClelland) have written on similar motivational themes.
What Could Go Wrong?
The problem occurs when organisations deploy a form of Agile that is not informed by motivational theory. The diagram below shows the worst-case scenario:
Some have referred to this model as Wagile and others as Water-Scrum-Fall. Whatever we call it, it is all about control.
We have a management layer that defines scope, timeframe, and budget of projects at a high-level. They do this by doing what they have always done, which is to generate and execute on prioritisation processes, build value cases, do cost-benefit analyses, and so on.
The scope, timeframes, and resourcing models are then passed down to Agile teams to get on with the delivery. Once projects are in progress, management monitor, control and, when necessary, take corrective action to ensure the targets are met and deadlines are observed.
Theory X styles of management are likely to prevail; after all, management have to ensure that the milestones are met. Management have made commitments to stakeholders, shareholders, and senior management, and they will be held accountable.
Human drivers, as mentioned above, are downplayed as deadlines have to be met, coding has to be done, and test cases have to be executed.
It’s like we are doing Agile but without the heart and soul of Agile. Ironically, the more management try to manage and control, the less likely they are of getting any productivity benefits.
So lastly, some advice for management teams who want their organisations to go Agile and reap the benefits of increased productivity:
- Relinquish Control: The more you control, the less autonomous the teams are, and the less motivated the team members are.
- Set Strategic Goals: Sutherland, in the book mentioned above, explains that it is the role of management to set strategic goals but the role of the team to decide on how to achieve these goals. These goals, however, should be goals and not commitments.
- Become Servant-Leaders: Offer support, advice, mentoring, and direction.
- Be inspirational: Explain why we need to do something, not what we need to do. Give teams problems to solve, not plans to follow.
- Remove blockers: One of the roles of the Scrum Master is to remove impediments. But what if management were there to help every time a blocker was impacting progress? Think how much faster the teams could work.
I believe Agile can bring about productivity increases because it taps into what motivates us, what drives us, and what makes us want to do the best work we possibly can. But we have to get it right. We have to adopt the heart and soul of Agile not just the nuts and bolts.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
