In interviews, I often describe Software Development as being:
Although I'm passionate about all three, I think the People component is the most important, but hardest to get right. My wife is currently studying Systemic Practice, in the context of Family Therapy. In our frequent discussions about each other's work, I'm finding significant overlap between Systemic Practice and growing great software teams.
Systemic Practice seeks constructive improvement, through bringing out, sharing and respecting the views and stories of all involved. Although this approach has a strong connection to Family Therapy, it can also be applied to any group of people. For more details, visit the Association for Family Therapy site or the Systemic Practice Index.
A Crisp team article recently made a similar connection in applying what my wife calls the miracle question, to Agile Retrospectives:
The key with this approach is to focus on a more positive future, and the steps to reach it, instead of spending time wallowing in ones current problems. A couple of the teams I work with tried this "positive thinking" method in recent retrospectives, and found it very, well, positive! It gave a much greater focus on the end-improvement, and the actions required to get there. Time will tell if the goals are actually reached, but I have every confidence.
Another Family Therapy technique I've often found useful is the use of curiosity to subversively cause change. If you'd like a person/team to adopt a new behaviour, then instead of asking them directly, or (even worse) telling them to, try this approach: take a neutral stance on their behaviour, but just think out loud:
Then wait for their response, without pushing or pressurising them for agreement. You may not get a positive response, or even any response at all, but given time and the right conditions, they may mull it over and their own curiosity will make them think this through. The result is often them picturing their change in behaviour and foreseeing some benefits, which they then voice themselves and buy into more readily than if you'd forced the change on them. This is because they are now the originator and owner of the change.
I've described just a couple of Systemic Practice techniques that can be applied to Software Teams. I'm sure there are many more, so I'll blog about new ones as I find them. I'd also love to hear from other Agile Coaches or Teams applying Systemic Practice, so we can share our experiences of what works (and what doesn't!).
People + Process + Product
Although I'm passionate about all three, I think the People component is the most important, but hardest to get right. My wife is currently studying Systemic Practice, in the context of Family Therapy. In our frequent discussions about each other's work, I'm finding significant overlap between Systemic Practice and growing great software teams.
Systemic Practice seeks constructive improvement, through bringing out, sharing and respecting the views and stories of all involved. Although this approach has a strong connection to Family Therapy, it can also be applied to any group of people. For more details, visit the Association for Family Therapy site or the Systemic Practice Index.
A Crisp team article recently made a similar connection in applying what my wife calls the miracle question, to Agile Retrospectives:
If you had a magic wand / could perform a miracle, what would your new future be like?
The key with this approach is to focus on a more positive future, and the steps to reach it, instead of spending time wallowing in ones current problems. A couple of the teams I work with tried this "positive thinking" method in recent retrospectives, and found it very, well, positive! It gave a much greater focus on the end-improvement, and the actions required to get there. Time will tell if the goals are actually reached, but I have every confidence.
Another Family Therapy technique I've often found useful is the use of curiosity to subversively cause change. If you'd like a person/team to adopt a new behaviour, then instead of asking them directly, or (even worse) telling them to, try this approach: take a neutral stance on their behaviour, but just think out loud:
I wonder what would happen if you tried <describe desired behaviour>."
Then wait for their response, without pushing or pressurising them for agreement. You may not get a positive response, or even any response at all, but given time and the right conditions, they may mull it over and their own curiosity will make them think this through. The result is often them picturing their change in behaviour and foreseeing some benefits, which they then voice themselves and buy into more readily than if you'd forced the change on them. This is because they are now the originator and owner of the change.
I've described just a couple of Systemic Practice techniques that can be applied to Software Teams. I'm sure there are many more, so I'll blog about new ones as I find them. I'd also love to hear from other Agile Coaches or Teams applying Systemic Practice, so we can share our experiences of what works (and what doesn't!).
