Values. Really?! Come on!
Introduction
Values are one of those over-used ideas that many of us roll our eyes when we hear it discussed (I strongly resemble that previous remark). To me, it lands in the same category as “empowerment” – over-used, rarely beneficial, mostly BS in the work world. However….
However, I’m writing a blog entry about values. As an individual, I have values that I feel very strongly about (even if many times they are implicit and I’m unaware of them). And I find that if I am in a place where my values don’t fit with the mainstream then I begin to not enjoy the work. And what may have been enjoyable and fulfilling in other circumstances is now a chore. For me personally, it grates enough that I end up leaving the situation if I can’t change it. And how do you change the values of an organization anyway?!
A Theory
The values of a team or an organization are pretty heavy stuff. What are the values of an organization anyway? The real ones, not the ones on a plaque – what are they? Here’s an idea: they are the culture of that organization. The culture of an organization is defined by the values of the group. They are usually invisible and likely different from the official ones written by the leaders with the help of expensive consultants.
But it gets a bit messy here because the values of the group are not necessarily the values of the individuals in that group. The values of the group are the expectations in the ether. (Sorry, don’t have a better definition, ping me if you do.)
Ok, so far we have: Values of the individual are present – we all have them and feel strongly about them – although we are not all aware of them. Values of the group are there also. However, they are not the total sum of the values of the individuals since we often find conflict between the values of individuals within the group.
When values of the group align with the values of individuals, something magic has the potential of happening. I don’t know if it always does – but those “magic teams” that I’ve personally witnessed and have been part of – have it. They have alignment between the individual and group values. Now, if those values happen to help produce great software – wow!
A Concrete Instance
So, I had a conversation with a very good friend of mine about his software development team and how there is a huge Us vs. Them between the business analysts and developers. The developers are not happy with the requirements – they are not concrete enough – and they want them right the first time. The business analysts are afraid of the developers since they sometimes provide less-than-perfect requirements. And if they ever change their minds once something has been built, and fail a story, even though it met the letter of the law, all hell breaks loose.
So, is this an agile team? Ok, I don’t really care that much if they are agile, but if we look at the behaviors we can see the following values executed:
- We succeed and fail alone – as individuals – not as a team. Developers are upset when business analysts fail a story even if the act of testing the code shows that the requirements were wrong.
- We prefer getting things right the first time over iterating. Developers want business analysts to get the requirements right the first time around and are upset when they don’t.
- Achievement is more important than respect and a safe environment. Business analysts are intimidated by developers and will sometimes overcompensate on their story writing creating waste.
My judgment may seem a bit harsh, and it is probably missing many of the nuances that are really happening on the ground. However this is not the first time I’ve seen this dynamic (sometimes reversed) and it is not unusual in software development teams.
Remember I said that “being agile” is not important, but creating software is very important. This is a product team, and innovation is extremely important. The lack of safety and lack of ownership evidenced here will always be in the way of this team’s ability to be innovative and become a high performing team. No amount of technical prowess can remove this dynamic; in fact, if there was more technical prowess on the team it may accentuate the problem.
I have been talking about individual behaviors leading the way to individual values. But if we trace back just a bit, to the culture and environment of the organization, we can learn some things too.
- There is no clear negative consequence to creating an unsafe environment. Does this mean that safety is not a priority?
- There is no clear negative consequence to claiming individual success while there is a failure in another part of the team. Does this mean that team success is not rewarded? Or maybe that individual success is rewarded much more than team success?
- There is no clear negative consequence to pushing for things to be “done right the first time” as evidenced by the backlash against business analysts changing their mind. Does this mean that there are people who are allowed to make mistakes (developers through the development cycle through TDD) and people who aren’t (business analysts getting feedback from working software and changing their minds)?
What would happen if ….?
What would happen if this team had a culture that values:
- Iterative learning.
- Learning through failure.
- Succeeding as a team.
- Ownership.
- Safety.
And furthermore, what would happen if these values were clear, upfront, repeated by management again and again whenever addressing difficult problems? Would people change? Maybe. Would everyone stay at the company? Probably not. Would they build better software? Absolutely.
In the end – it is much easier to poke holes into something out there when you are not that close. My friend who related this story is one of the single best managers I’ve met in my life. He sees these issues and works on them, and in the end, I’m sure he’ll find a path to lead his team out of these difficulties.
miguelbgouveia
May 28, 2013 at 11:09 am
In software development we must start ending with being afraid of failure. We must see in every failure an opportunity to make the difference. Great post, congratulations.
Kelly Arrey
January 7, 2014 at 2:22 pm
Hi Amr, is it possible that characterizing the business analysts improved understanding of the requirement as “failing” the story is part of the problem ? It could easily be perceived as blaming development for something that was out of their control. Also, pressure on development to deliver now contributes to their wish for the BAs to “get it right the first time”.
samadisy
January 7, 2014 at 3:41 pm
Hi Kelly,
Blame is a killer for teamwork, so yes it is possible, perhaps even probable. Blame is usually done to protect oneself and to push failure over to someone else.
So, in a safe environment that encourages learning from failure and does not give kudos for individual success, how likely is it for people to blame each other?