Reformulating the Product Delivery Process
Israel Gat, Erik Huddleston and Stephen Chin present how Inovis realized a higher product throughput by using three unconventional Kanban practices and a Lean Release Management tool called APROPOS.
Tracking change and innovation in the enterprise software development community
Posted by Shane Hastie on Feb 05, 2010
In the January-February 2010 edition of Harvard Business Review as part of an article on "Breakthrough Ideas for 2010" Teresa M. Amabile and Steven J Kramer wrote about their research into what really motivates knowledge workers.
Contrary to current management thinking, the number one motivating factor is no longer Recognition. They state:
In a recent survey we invited more than 600 managers from dozens of companies to rank the impact on employee motivation and emotions of five workplace factors commonly considered significant: recognition, incentives, interpersonal support, support for making progress, and clear goals. Recognition for good work (either public or private) came out number one.
Unfortunately, those managers are wrong.
The reality is the single most motivating factor based on a multiyear study tracking the day-to-day activities, emotions, and motivation levels of hundreds of knowledge workers in a wide variety of settings is PROGRESS.
On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak. On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.
The study was conducted by having knowledge workers keep a daily diary and rank their emotions and motivations on a daily basis. The results show that making progress in a work activity, even small incremental progress, is more motivational than any other single factor.
The article includes the following graph showing "What happens on a great workday":

They go on to provide advice to managers about how to keep their workforce motivated:
Managers have powerful influence over events that facilitate or undermine progress. They can provide meaningful goals, resources, and encouragement, and they can protect their people from irrelevant demands. Or they can fail to do so.
Scrupulously avoid impeding progress by changing goals autocratically, being indecisive, or holding up resources. Negative events generally have a greater effect on people’s emotions, perceptions, and motivation than positive ones, and nothing is more demotivating than a setbackthe most prominent type of event on knowledge workers’ worst days.
The go on to point out that recognition is still a valuable motivating factor:
As for recognition, the diaries revealed that it does indeed motivate workers and lift their moods. So managers should celebrate progress, even the incremental sort. But there will be nothing to recognize if people aren’t genuinely moving forward, and as a practical matter, recognition can’t happen every day. You can, however, see that progress happens every day.
Their identification of progress as the most motivating factor for knowledge workers build on and agrees with factors identified as far back as 1981 by Barry Boehm. In a 2004 Agile Times article - "Motivation, Teamwork, and Agile Development" - Giovanni Asproni cites Boehm’s Top Ten Motivational Factors for Sofware Developers as
1. Achievement
2. Possibility for growth
3. Work itself
4. Recognition
5. Advancement
6. Technical supervision
7. Responsibility
8. Relations with peers
9. Relations with subordinates
10. Salary
He states "The data on which the list is based is more than 25 years old, but I think it is still valid, since it matches pretty well with my experience."
What motivates people in your teams, and how do management practices support or detract from these motivating factors?
Do the Agile practices (short iterations, rapid feedback, daily standup ...) make working on Agile teams produce more positive motivational experiences for the team members?
A ScrumMaster’s Checklist: Product Owner, Team, Dev Practices, Organizational
Managing Agile: Transforming the Three Dysfunctions of Management @ QConSF Nov 1-5
Collaboration, facilitation, leadership, coaching and team building - new skills required for Business Analysts on agile projects. Download the Agile Business Analyst to read more.
Thank you for spotting and sharing this!
When a manager or ScrumMaster removes impediments raised by developers, yes, it helps them feel they are making progress. When s/he shows a nice Burndown chart going down, yes, it does make the team feel they are making progress.
On the contrary, when a manager sets arbitrary rules about how people should do their work, or creates impediments rather than removing existing ones, (non Agile practices), this article explains why this has a devastating effect on productivity and motivation. As the article puts it: "You can proactively create both the perception and the reality of progress. If you are a high-ranking manager, take great care to clarify overall goals, ensure that people’s efforts are properly supported".
It also says: "refrain from exerting time pressure so intense that minor glitches are perceived as crises rather than learning opportunities." Short iterations (and, in general, artificial deadlines) may create problems when things are half done and no progress is recognized.
Demonstrations help a lot with recognition of actual work done (not documents or lines in Project Plans marked as "completed"), and I've always forced them upon shy developers. Now it's giving one more argument why I should continue pushing them :-)
Daily standups can also help "Cultivate a culture of helpfulness" if team members share their problems and offer to help.
One new thing that comes to my mind is this: since most the work of us "knowledge workers" is to acquire knowledge, how do you recognize progress is that context? Maybe one of the questions during daily standups should be "what did I/we learn yesterday?"
Also at the grassroots level, TDD makes programming more fun, because it gives a sense of progress within minutes, when you get one more test case to pass every couple of minutes.
As per my experience, make progress does motivate people a lot.
This is part of why agile works but there is a lot more going on than just a great sense of progress. I wrote about this a few years ago: agilepainrelief.com/notesfromatooluser/2007/06/... and agilepainrelief.com/notesfromatooluser/2007/07/...
Cheers
Mark Levison
Agile Pain Relief Consulting
I've always been the most productive on teams with strong managers who really go out of their way to help lessen the resistance of organizational change. Knowledge work is all about change and progress. The worst feeling in the world as a worker is to believe you're making progress in spite of management support, rather than because of it. Motivation goes through the roof when companies attract forward thinking managers who help facilitate the kind of change that puts team members in a position to deliver faster and deliver higher-quality work.
Israel Gat, Erik Huddleston and Stephen Chin present how Inovis realized a higher product throughput by using three unconventional Kanban practices and a Lean Release Management tool called APROPOS.
Ross Mason discusses how to use enterprise mashups by applying a number of patterns, such as FeedFactory, Super Search, and Pipeline, in order to find new ways to benefit from existing enterprise data
Udi Dahan discusses the Command Query Responsibility Segregation (CQRS) pattern, detailing on queries and commands, what they are and how they should be used in an asynchronous programming environment
Olivier Mallassi shares a story of a typical software development project, some typical problems and what he learned from Tom Demarco about addressing those problems, and an alternative story.
Ralph Johnson discusses principles, practices and tools relating to software development starting from already existing code which needs refactoring, maintenance, and sometimes architectural change.
At a recent IIBA New Zealand members event Shane and Pete debated the role of the business analyst on Agile projects. They looked at the importance of analysis on projects and how the role changes.
Pete Goodliffe provokes his listeners to keep learning, offering advice on how to approach learning, what is valuable and what can be ignored, how to deal with new things, having a healthy attitude.
If you want a job in Agile software development, using a framework like Scrum, you need a plan of action that spans all three phases of your job search: preparation, interviewing, and assessment.
5 comments
Watch Thread Reply