Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic.
“Can you share with me your reasoning?”, I asked him intrigued.
The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction.
Indeed, I thought to myself. Who said people and teams shouldn’t be given clear objectives. On the contrary, in my opinion, clear goals are necessary for teams to organize otherwise you end up with a bunch of people who will try to find a reason, a purpose why they are all together – and their self-created goal may very well be different from what you had in mind in the first place.
Where I have a problem is that people associate self-organized teams with “abandoned teams” meaning you simply let the team figure it out – whatever “it” is.
In order to reach the level of autonomy they need to demonstrate extra-ordinary performance, teams need to reach the right level of maturity. Consequently, the manager’s leadership style is critical to achieve that objective. Within Pyxis, we often rely on the combination of the situational leadership and the group development stages to determine the proper level of involvement from the manager.
One of the way to achieve the right level of maturity is for agile managers to determine WHAT must be accomplished and let the team determine HOW it will be done – I already shared my opinion on this topic. Granted, things are more complex that I make them sound in this post but self-organization is indeed possible when the right environment is created for the team – including clear objectives – and it is then given the latitude to operate and determine how best to achieve the given goal.
If only managers would be willing to let go some of their (need to) control and trust the teams, a higher level of performance can be attained.
As you may have guessed, the candidate wasn’t called back for a second interview…
My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.
As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.
Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.
I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.
As such, my first impression to the conversation that was going on were:
Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time
It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.
If you work in an Agile environment or better yet, if you manage people who have embraced the Agile principles, you have certainly bought into the concept of self-organized teams. The underlying assumptions are that:
People are more motivated when they are self-organized;
People take their own commitments more seriously than the commitments made by others on their behalf;
Teams and individuals are more productive when they are not interrupted;
Teams improve when they can settle their own issues;
Changes in the composition of the team affect the productivity of the team members;
Face-to-face communication is the most productive way to share information.
Needless to say, management hasn’t changed much in a hundred years with its need to control and its chief tools remain extrinsic motivators.
Taylor believed that work consisted mainly of simple, not particularly interesting tasks and that the only way to get people to work on them was to incentivize them properly and monitor them carefully. Later on, Maslow developed the field of humanistic psychology in the 1960s (which questioned the idea that human behavior was purely ratlike seeking positive stimuli and avoiding negative stimuli) and McGregor challenged the assumption that humans are fundamentally inert (in the absence of external rewards and punishments, we wouldn’t do much).
In his most recent book (Drive: The Surprising Truth About What Motivates Us – audiobook format), Daniel Pink presents many factoids taken from scientific researches to demonstrate how people can (and can’t) be motivated. Although the author brings a scientific perspective to people motivation, the book is easy to read in addition to being entertaining.
Scientists then knew that two main drivers powered behavior. The first was the biological drive (comes from within) and the second comes from without – the rewards and punishments the environment delivered for behaving in certain ways [...] The third drive – performance of a task provides intrinsic reward. The joy of the task is its own reward.
Autonomy, Mastery, and Purpose
In his book, Pink states that human beings have an innate inner drive to be autonomous, self-determined, and connected to one another.
Autonomy
The opposite of autonomy is control. Control leads to compliance; autonomy leads to engagement.
Pink’s book provides valuable scientific explanations to the concept of self-organised teams. He presents the ROWE (Results-Only Work Environment) concept and the Self Determination Theory (SDT) to demonstrate the relationship between autonomy and well-being. He goes further to associate autonomy with higher productivity, less burnout, and greater level of psychological well-being. More closely related to software development, the author presents the level of authority given to employees at software giant Atlassian where people decide: what they do, when they do it, how they do it, and whom they do it with.
Mastery
The desire for intellectual challenge (the urge to master something new and engaging) was the best predictor of productivity.
Daniel Pink explains that people are motivated by self-development and learning of new skills or developing existing abilities. The actual challenge of mastering a discipline is often a better motivator than money can be (assuming a minimal level of income). Similar to children who easily get motivated with playing – which is a way for them to learn and master a skill – managers can leverage that ability to motivate individuals.
As such, human beings are said to have an inherent tendency to seek out novelty and challenges to extend and exercise their capacities to explore and learn – which are in themselves powerful motivators.
Purpose
The science shows that the secret to high performance isn’t our biological drive or our reward-and-punishment drive, but our third drive – our deep-seated desire to direct our own lives, to extend and expand our abilities, and to live a life of purpose.
The author points out that many psychologists and economists have found that the correlation between money and hapiness is weak – that is past a certain level, a larger pile of cash doesn’t bring people a higher level of satisfaction. As such, contrary to traditional motivational techniques, money does not increase happiness and performance – some research have actually demonstrated the opposite effect! It is possible to keep people highly motivated without constantly leveraging money as a motivator.
Human motivation seemed to operate by laws that run counter to what most scientists and citizens believe. When money is used as an external reward for some activity, the subjects lose intrinsic interest for that activity. Rewards can deliver a short term boost but the effect wears off and worse can reduce a person’s longer-term motivation to continue the project.
In direct contravention to the core of tenets of motivation 2.0, an incentive designed to clarify thinking and sharpen creativity ends up clouding thinking and dulling creativity. Why? Rewards, by their very nature narrow our focus. That’s helpful when there’s a clear path to a solution. They help us stare ahead and race faster but “if then” motivators are terrible for challenges. The rewards narrowed people’s focus and blinkered the wide view that might have allowed them to see new uses for old objects.
Carrots and Sticks – The Seven Deadly Flaws
They can extinguish intrinsic motivation
The can diminish performance
The can crush creativity
They can crowd out good behavior
They can encourage cheating, shortcuts, and unethical behavior
The can become addictive
The can foster short-term thinking.
The relation to software development
Algorithmic tasks are tasks in which an individual follows a set of established instructions down in a single pathway to one conclusion. That is, there’s an algorithm for solving it.
A heuristic task is the opposite precisely because no algorithm exists for it, individuals have to experiment with possibilities and devise a novel solution. Software development is a heuristic task.
During the twentieth century, most work was algorithmic but as McKinsey & Co. estimated that in the United States, only 30 percent of job growth now comes from algorithmic work, while 70 percent comes from heuristic work.
Researchers have found that external rewards and punishments – both carrots and sticks – can work nicely for algorithmic tasks but they can be devastating for heuristic ones.
Conclusion
If you need scientific explanation and useful examples to explain to people around you why a self-organized (autonomous) team with team members who are striving to develop their skills in an attempt to reach a common purpose is possibly the most impactful motivator, you may want to read this book.
In conversations with upper management, I often hear that they wish to start using an Agile approach to increase their return on investment (ROI) and the employee motivation – which is great! They have read or have been told that changing their approach should lead to:
Delivering solutions that meet the business needs…
…without exceeding time lines or costs and…
…increase efficiency and productivity.
Many people manager (although not all) understand that people are more motivated when they are self organized and as such, take their commitments more seriously than if the commitments were made by others on their behalf (i.e. their manager).
What is news to many of these managers is the impact an Agile transition will have on them – and their management style. I like to point out that to them that:
Teams and individuals are more productive when they are not interrupted;
Team performance improves greatly when people settle their own issues;
Changes in the composition of the team affect the team’s productivity.
As such, people manager need to learn to:
Transfer the authority and the responsibility to the team members to allow them to do their job properly;
Avoid interference and micromanagement;
Promote collaboration and teamwork;
Support learning without systematically penalizing failures;
Establish a culture conducive to Agile projects;
Adapt their management style to the context of team.
Eric’s great posts on project management, comparing Scrum and PMI
One of my preferred antagonists was the all mighty monolithic Project Management Institute (PMI) and its PMP disciples. In an attempt to keep my friends close and my PERCEIVED enemies closer, a colleague and I decided to attend the PMI bootcamp – a five day course to prepare for the PMP certification. - An Agile coach’s journey into PMI country – Day 1 – I’m very disappointed! | Pyxis blog.
What we’ve got here is process number 3.4.4 in the PMBoK and this, I believe, is where the PMI got cocky. WBS is so central to the PMI that our trainers would actually say that if you don’t have the answer to a certification question and WBS is one of the options – choose it! - An Agile coach’s journey into PMI country – Where PMI got cocky. | Pyxis blog.
Isaac’s post on why CIO should love Agile Development
In agile, the CIO is getting the following significant advantages: Low up front business investment (…) Frequent delivery leads to better execution (…) Allowing Sponsors to prioritize at the beginning of each iteration leads to better Business / IT alignment (…) . - Social, Agile, and Transformation: Why the CIO Loves Agile Development.
Israel’s post on why the Agile triangle should replace the Balanced Score Card
On the value of building trust and respect within teams
This is because people are the engine that drives a high performance project. Without a good team that embodies trust and respect, the best process and tools in the world will not help you. I am as geeky about process as the next agilist, I love experimenting with Kanban and Lean and know that they offer better ways of executing projects. However, bigger improvements can be had from the people side of things. - LeadingAnswers: Leadership and Agile Project Management Blog: Building Trust and Respect.
On Recruiting “Normal” employees
I want/need to hire someone. Not a difficult task, right? I've been doing this for years and it's a simple process. I mean let's be honest – I'm not trying to launch the Space Shuttle into outer space – I just need to hire one “normal” employee. And therein lies my problem: “Normal Employee” wanted. - Fistful of Talent: Wanted: Normal Employee.
On Communication
John Gottman’s pioneering research found that marriages are much more likely to succeed when the couple experiences a 5 to 1 ratio of positive to negative interactions whereas when the ratio approaches 1 to 1, marriages are more likely to end in divorce. Additional research also shows that workgroups with positive to negative interaction ratios greater than 3 to 1 are significantly more productive than teams that do not reach this ratio. - Jon Gordnon’s Blog: The Power of Positive Interactions
Nicholas’ post on Ergonomic design
People will not care how well something is built if it is not appealing to them first and easy to use. Car designers and software designers alike are victim of this reality. - Ergonomy lessons learned : Ergonomy sells. | Pyxis blog.
Is there a person in charge? Completely decentralized organisms have no head, as in there is no “head” of the Internet. They relate a funny story circa 1995, when a CEO looking for startup funding couldn’t convince a room of potential investors that there wasn’t an Internet president — the concept was beyond them. - The Cutter Blog » Blog Archive » Understanding the Nature of Self-Organizing Teams.
On why an Agile approach is better suited to deliver value (Thanks to Alfonso)
Most organizations that depend on software are struggling to transform their lifecycle model from a “development” focus to a “delivery” focus. This subtle distinction in wording represents a dramatic change in the principles that are driving the management philosophy and the governance models – Improving Software Economics
On the meaning of Agile transformation for managers
What many people mistakenly do is equate agile project management with doing more work, with less documentation and fewer people. Although the premise is to get more done in a more favorable way, I have never met a team that could successfully implement agile principles without having to slow down first - VersionOne – Agile Adoption For Managers.
On the fact that the true value of an organization is not mapped via its organizational chart
On the need to manage self-organized teams when required
The interesting thing is, the further we go into agile management territory the less typical the managerial job we expect. Teams are self-organizing and cross-functional, and sometimes we think a manager should just get out of the way. By the way, surprisingly often this is exactly the best choice. But whenever one of the asshole-moments is needed, it is time to show up and do what has to be done. Otherwise the atmosphere starts rotting as people wait for someone who will fix things. Someone who will do something about this guy adding a new technology every time he reads some nice article. Someone who will deal with that lass taking a few days off because she doesn’t really care about the project being late and the team working their butts off to get back on the right track. That’s always a job for a manager, and a harsh one, no matter how self-organized the team is - Good Managers Sometimes Have to Play Assholes – NOOP.NL.
I attempted a small experiment with my kids a few weeks ago – get them to voluntarily help clean the house. If you have children between 7 and 10 year-old, I’m pretty sure having your kids help with cleaning is nothing short of a nerve-wrecking experience. If you don’t have kids, the process typically goes like this:
You – “Timmy, can you please pick up the toys in your room.”
Timmy – “Why?”
You – “Because your room is a mess and I break my face every morning when I come wake you up.”
Timmy – “OK, I’ll clean up.”
30 minutes later, you go see Timmy.
You, slightly annoyed – “Timmy, what are you doing?”
Timmy, looking up – “I’m building a castle, daddy. You want to play with me?”
You – “Yes, I’d like to play with you as soon as I’m done cleaning up. Why didn’t you pick up your toys like I asked you too?”
Timmy – “OK, I’ll clean up”
30 minutes later, you go see Timmy
… (you can guess the rest)
So, back to my experiment. A few weeks ago, while my wife was grocery shopping I decided to use an adapted version of Scrum. I called my son and his twin sister and told them we would do a little activity. To their enjoyment, they were wondering what I had in mind. They sat next to me at the table while I the took 4 x 6 index cards and on each of them, I wrote a task: pick up the toys, put your clothes in your drawers, empty the garbage cans, bring the recycling to the garage, put the Tupperware away in the drawer, vacuum the floor, etc.
My son – “Daddy, why are you writing these down?”
Me – “We’ll play a little game.”
My daughter – “Can I play too?”
Me – “Of course. Here’s how it goes. I wrote 8 cards and each card has a little task. I need you to help me clean up the house while mommy is doing grocery.”
The twins – “OK, what do we do with the cards?”
Me – “You will each select the cards (the tasks) you would like to do. You then decide in which order you want to do them.”
My daughter – “Daddy, some tasks are longer than others. What do we do about that?”.
Me – “It’s up to you to decide.”
The twins – “It doesn’t matter. We’ll decide which ones we pick.”
My son – “Do we get a reward for doing the work?”
Me – “Mmmm, good question. I know you like to read. How about I give you tokens for each task? Once you get 50 tokens, I’ll buy the book you asked me.”
My son – “OK.”
My daughter – “Can I buy a beeds set instead of a book?”
Me – “Sure.”
The twins – “Can you write how many tokens each task gives on the cards?”
Me – “Good thinking! Picking up the toys is 3 tokens, bringing the recycling to the garage is 1 token, …”
The kids – “OK, but who picks first?”
My son – “Let’s do rock – paper – scissor.”
My daughter – “Yes, let’s do rock – paper – scissor.”
The twins – “ROCK, PAPER, SCISSOR…”
After determining who would start, they quickly picked the cards and started doing the assigned task. At their own pace, they executed on the cards. Then, something cool happened.
My son – “Daddy, can we add a card? We need to water the plants.”
Me, laughing – “Of course. Who’s going to take this one?”
The twins – “Me, me, me!”
Me – “I guess we’ll have to write another card so you are even.”
My daughter – “Can I dust the bureau? I saw mommy do it the other day and I’d like to do that.”
Me, with a big smile – “OK, if you’d like to do that. I’m OK with this.”
Together, they successfully completed all their tasks. All of their tasks! No fighting, no screaming. That was a “proud moment” Imagine when my wife got back home after the grocery…
With the Xmas Holidays and the broken routine, I was pleased to see my kids grabbing the cards by themselves this past Saturday and starting to execute on the routine. “Wow, this self-organization thing really works! Even with kids…”, I told myself.
The Take-Away
If you want people to carry out a task, here are a few suggestions:
Describe the task;
Let the team self-organize;
If the team needs help, you may suggest tools or a process – but do not impose them;
This blog discusses new leadership paradigms and innovative organizational structures with the intend of improving teams' performance and people's quality of life at the office.
In September 2009, I decided that for the next year, I would concentrate on three goals: Reading (12 books) Blogging (40 posts) Coding (4 projects) What did I learn about setting objectives? What do I need to improve? These questions will be answered in a few moments… and if you care you might even hear […]
There’s a misunderstanding I’ve noticed in quite a few Scrum projects. Teams use Scrum and at the end of their sprint they do what they call a “sprint demo”. It works out like this: They demonstrate their increment of the prod... […]
Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic. “Can you share with me your reasoning?”, I asked him intrigued. The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction. Indeed, [... […]
Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement. Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de […]
Written in collaboration with Carl Létourneau What’s the problem? Creating software without bugs is hard. Many developers are used to unit test their models. Controllers are also relatively simple to test in many frameworks. Tests often hurt when it comes to Views – many frameworks make it hard, or developers might think it is. Sometimes we just […]
This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned. One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D). For most of […]
Since I discovered Haml for my HTML templates in Rails, I stopped using ERB. Haml is more intuitive and readable to me. I am rediscovering ERB though for something else completely – Java code generation. There is a lot of boilerplate code in most Java projects. A good IDE can help you alleviate some of […]
I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time. In agreement with his teams, Steven initiated an Agile transition a few months ago. I [...] You might be interested […]
Now that the vacations are over and that the 2010 Agile conference has come and gone, Team Urban Turtle is back to work, cooking up another promising release 3.4. With the release of the Scrum template from Microsoft came a Removed state, making it necessary to propose a recycle bin feature to our […]