In the previous post I was mentioning that a company culture is anyway emergent and what emerges cannot really be predicted, but can be influenced in many different ways.
Here’s one way to do that, which I found very useful when working with agile teams.
A big part of the agility is based on values and principles, be it the XP ones or the Agile Manifesto ones, or the lean ones. But how are values and principles playing together? How do they exactly help us?
Values, principles and beliefs are actually interworking together to define the identities of individuals, teams and organisations. As a change agent in an organisation, one of my objectives is to support a common identity in the teams (even better in the whole company) as this will create alignment, agreement and, in the end, teamwork.
So here are the driving questions your team should answer in this type of work:
- What are the values and principles you want to promote in your team? There are a lot to choose from in all the agile practices!
- What are the values and principles that give you most of the value in improving the team?
- How do you set up a feedback mechanism to enable your self-organising teams to improve themselves based on those values? Hint: solution focused scales and retrospectives!
- How do you set up a feedback mechanism to enable your self-organising teams to reflect on what values and principles they need to work next? Hint: retrospectives again!
- What are the values that are instead damaging the team and should be dampened?
By raising awareness on values and principles, we are effectively stimulating an evolution of the emergent identity in a direction that will eventually support an effective agile implementation.
P.S. Be aware values work is not for the faint-hearted and it’s not easy: consider that conflicts can be re-conducted to a values disagreement!
In your blog I read:
“Values, principles and beliefs are actually interworking together to define the identities of individuals, teams and organisations.”
This is interesting, because from the point of view of “Solution Focused Work” I see the practice differing from this. Solution Focus acts as if humans are neither driven from the inside by some kind of mentalistic (or even molecular) framework, nor from the outside by systems or social forces. One conventional psychotherapy wisdom holds that an individual’s behavior and interactions with others are driven by internal mechanisms hidden from view, and that in order to change behavior the internal mechanisms must be changed. This is like adjusting a machine or some kind of computer program – as if people were at the mercy of bugs in their operating systems. There are two forms of mechanisms to consider – mentalistic and molecular.
Typical mentalistic mechanisms include:
* Beliefs
* Personality Traits
* Attitudes
* Motivations
* Values
* Thoughts
* Emotions
* Psyches
* Mental Maps
* Weaknesses
* Strengths
* …
SF (Soluiton Focused) practice does not follow this conventional wisdom. Solution focused coaches / therapists do not make assumptions about any of the above and they do not try to change them. People in solution focused coaching / therapy can and do change their lives and leave all manner of problems, diagnoses and other ailments behind them without any use of, reference to or mapping of these internal ‘things’. Indeed, even problems declared by clients in such terms can be handled quite satisfactorily by using and building everyday descriptions of their lives.
Please heave a look in this text for more details:
http://www.sfwork.com/jsp/index.jsp?lnk=6d8
Cheers,
Hans-Peter
Hans-Peter,
Thanks for your contribution. I agree on what you wrote. But the subject of my post is a technique that has little to do with solution focused, if at all.
What I sketched there is actually derived from the neurological levels of NLP by Robert Dilts, though cleaned up of the non-systemic aspects and adapted for the purpose of working with agile teams.
This method gives me a framework to dissect agility in some “components” and discuss about them with the team. In fact, it is more a way to start talking about the various aspects of agile rather than a real method in itself.
I of course let the team members decide what parameters they are to monitor and to act on and they are allowed to change them at each retrospective if they feel they need.
Pierluigi