Chase after money and security
and your heart will never unclench.
Care about people’s approval
and you will be their prisoner.
Do your work, then step back.
The only path to serenity.
– 老子, Lao Zi (hundreds of years before our common era)
We live in a goal-oriented culture. Therefore, it’s no mystery that many people feel that the pursuit of luxury cars, expensive degrees, high status positions, and culturally valued physical appearances are the paths to life satisfaction. However, many studies, including one done by Kasser & Ryan (1996), concluded that when people focus on externally validated goals rather than internally validated values, they have a significantly lower amount of well-being.
A study conducted by Chase, et. al (2013) on undergraduate student GPA found that when values are included along with goal-setting, there is a significant increase in student GPA. With goal-setting alone, there was no significant improvement in GPA. One of the biggest problems they found was a lack of distinction between goals and values. Values are much different than goals. According to one psychological model known as ACT, “values are freely chosen, verbally constructed consequences of ongoing, dynamic, evolving patterns of activity, which establish pre-dominant reinforcers for that activity that are intrinsic in engagement in the valued behavioral pattern itself,”(Wilson & Dufrene, 2009, p. 66). As such, values require a deeper cognition. Appreciating the connections between things, or giving help freely are examples of values, where goals are merely outcomes such as losing five pounds or saving $100.
How does this relate to IT?
Goal-oriented work makes up almost the entirety of tasks in IT. Take agile sprints, for example, the predominant way in which software teams work. (I’m not implying that goal orientation only applies to agile teams, but rather the specifics I’m going to use come from the agile lexicon because it’s the most popular approach.) Even though the Agile manifesto states the intent of Agile is “people over process,” I don’t really ever encounter this in my contract work. I encounter “business owner satisfaction over everything else.” Point velocity, deployments without bugs, and reactions of the business determine satisfaction most often. These characteristics all fall into the goal-oriented, externally validated bucket. When the sprint burndown looks great, but the CI server is a mess and tests are failing, managers might feel great, but the team usually feels unhappy, if not demoralized.
Agile with values?
Point me to the team that derives success from asking whether or not the most recent chunk of software was created according to a set of internally validated values. Now there would be a true unicorn startup. Imagine a team that decides that following a set of values would determine the success or failure of an agile sprint. Some of these values might be: not taking shortcuts, communicating honestly and expediently with team members when my work affects others, seeking constant learning, seeking mentorship, staying focused.
On a team that does agile with values, during a sprint retro, for describing something that went well, team members would likely say things like, “Jenny and I communicated regularly on task 123.” For something that didn’t go well, team members might say something like, “We took shortcuts to get the comment feature finished.”
Things like this do get said in agile retros and quite often–because most developers have strong internal value systems. The problem is that these internal value systems don’t receive upward support. The project manager typically doesn’t absorb the fact that making space for the developer team to work according to its internal values will allow the team members to generate a lot of satisfaction and well-being on their own.
Instead, something like, “We had this many points completed this sprint, which was 20 points lower than last sprint” gets reflected back to developer teams. The message to the team is clear: All we care about is points, and that is all you should care about, too. Developers shake their heads knowing that while most other developers around them share similar values, no one else in the organization likely does. What they care about is the output–were the goals met? And so catered food and video games are introduced as a replacement for what teams actually want–which is for management to empower and truly encourage dev teams to work accoring to values that inspire and provide meaning and a sense of pride.
Why aren’t we working according to our values?
The irony is that if team cohesion, satisfaction, and well-being are all high because the team culture is one of working according to values, productivity will also increase. Why? I’ll give you the short answer. When people and teams are stressed out, they don’t think as clearly, they don’t problem solve as effectively, and all forms of cognition decrease, say Pfaff & Pfaff (2012). Fixating on story points and burndown (or burnup), leads the team to be stressed out, and/or feel like the team’s values don’t matter. Research indicates that living by values increases satisfaction, which implies that if teams focus more on values, morale and also cognition will likely increase as a result.
However, this approach involves trust and a willingness for managers to let go of their reports and spreadsheets that are 100 percent quantitative and move toward qualitative assessments of sprints. This typically doesn’t make those analyzing the reports happy, which of course is their primary concern, not the well-being of the team. They want 10s, 30s and 100s, not qualitative data like “mentored,” “openly communicated,” and so on. This weakness knows no bounds. There is a huge reluctance or gap in knowledge when it comes to approaches that use qualitative data. Much of the work in psychology relies upon qualitative data, and many great research endeavors have seen successful results from using it. But it’s harder, and most people in the field want easier.
Another reason why we’re not working according to our values is that management feels the need to tell teams what’s important and what should give them a feeling of satisfaction and well-being. But developers already know; they just need people to leave them to it. But this approach requires giving up control and allowing teams to live according to their values, which many managers aren’t comfortable with. Most organizations fear self-empowered teams. Managers often want to be able to use external motivators to encourage teams to hit their marks.
So round and round we go chasing goals with an absence of values, wanting more well-being and satisfaction within our teams but ignoring all the research that informs us about how people work because it conflicts with our short-term, selfish desires.
Imagining a different way
But is it really any surprise that IT operates this way when our American culture operates in a similar fashion? What do we care more about, how much we are impressing our Facebook friends and Twitter followers, or how curious we are about the world we live in? Do we care more about the number of likes on our Instagram posts, or how connected we are with those we encounter in our daily life? We crave a values-driven life but substitute external goals for that. (By the way, people will spend a lot more money on stuff when they aren’t values-driven, which works out great for those selling stuff.)
But a values-driven economy could work just as well in an IT agile economy. Let’s explore this, starting with an examination of points. Right now, stories are broken up into tasks, or whatever unit a particular team uses, and sizes or points are assigned to it based upon how much work it is, or some close approximation. At the end of the sprint, the project manager, or report generator person, clicks the button and either looks down their nose and says, “Velocity was down,” or smiles and says, “Good job, team.” This is a caricature of a PM, but you get my point.
In a values-driven, agile economy, teams still work with stories and tasks, but instead of only points being assigned an estimate based on how much time it will take to complete a story, points can also be assigned based upon the types of values that we want to be applied to that particular task. For example, if the team has a junior member who needs mentorship, they can decide that to do this task according to their values, the junior developer needs to receive some quality tutelage. She must be mentored for that story to receive points. If not, no points. The team decides the criteria for determining partial points depending upon how much of the value a developer gives the task. Teams still need to estimate how much work can be done in a sprint, but the generated reports also track values-driven work rather than just how much work was done. The same number of hours are exerted by the developer, deadlines must still be met, but the experience of agile with values affects the developer psychologically in that the work creates meaning, well-being, and long-term satisfaction.
One may argue that contrasting a values-driven approach with a goal-oriented approach yields no difference since now we are just complementing the amount of work with how the work was done. However, how the work was done is the exact qualitative difference that results in well-being and the factor that IT currently doesn’t give two shits about. You can argue that living by values is just another form of goal-oriented living, just not one that can be measured by wealth, likes, friend requests, or story points. But that’s not true. The key difference is that one method uses external orientation while the other uses internal orientation. One looks out, one looks in.
With traditional point systems, progress is tracked by looking only at task goals. An entire world of more important and meaningful data is being lost, which is data about how the work is being done. When progress-tracking is treated this way, developers learn to hit targets each sprint, but beyond that, no one cares what values were exercised or how developers felt about the job. In other words, it couldn’t be any more hollow. Is it any surprise that there is little satisfaction and well-being in this way of working versus one where meaning is baked into the process?
Compare a team who thinks thoughts like, “I need to get mentored in this area so that we get full points for this story,” or, “I need to communicate to the team each time I change a contract in the API for this story” to a team that instead thinks thoughts like, “This is a six-point story. I could stand to learn a little more about this tool, but I’m worried about my point velocity this sprint.” Most developers have values-driven thoughts regularly but specifically ignore them because they don’t directly contribute to getting the task done and earning the points for the sprint. Why is IT so clueless about this? These thoughts are resources to be mined and exploited (if I have to use a business term to get people’s attention). If teams’ values were given an avenue to emerge, not only would quality go up, but so would retention and recruitment since the dev environment will be one that people actually want to work in.
Let’s try something different
Empty points systems based on time estimates disincentivize developers from constantly learning, mentoring others, spending extra time to document and communicate, not taking shortcuts, and so on because our goal-oriented culture only cares about how quickly something is done and cares little to nothing about working according to values. I don’t care what the lip service is: If we’re being honest, this is the truth about working in almost all IT environments. We track the wrong things for the wrong reasons and then wonder why disappointment and low satisfaction abound. Let’s try something different.
Ian Felton - The Psychologist Coder
P.S. In my next posts, I will follow-up with workshops to use with your team to move toward an agile with values culture.
P.P.S. If you’d like me to come in and help you with agile with values with one of your teams, contact me.
Chase, J. A., Houmanfar, R., Hayes, S. C., Ward, T. A., Vilardaga, J. P., & Follette, V. (2013). Values are not just goals: Online ACT-based values training adds to goal setting in improving undergraduate college student performance. Journal Of Contextual Behavioral Science, 2(3/4), 79. doi:10.1016/j.jcbs.2013.08.002
Kasser, T., Ryan, R.M. (1996) Further examining the American dream: differential correlates of intrinsic and extrinsic goals. Personality and Social Psychology Bulletin, 22, pp. 280-287
Pfaff, M., & Pfaff, M. S. (2012). Negative affect reduces team awareness: the effects of mood and stress on computer-mediated team communication. Human Factors, 54(4), 560-571.
Wilson, K.G., Dufrene, T. Mindfulness for two: An Acceptance and Commitment Therapy approach to mindfulness in psychotherapy New Harbinger, Oakland, CA (2009)