Confronting shame, pride and ego in Agile teams

My neighbour rang my doorbell yesterday because her elderly husband had fallen over and she needed a hand helping him back up into his chair.  Immediately after I helped her out, she seemed rushed to forget all about the occurrence, almost as if she had felt some degree of shame, or her pride would be damaged somehow.

This morning, I went back over to make sure he was still doing okay and to let her know not to hesitate if ever she needs anything else.  Why should she shy away from this?

I lived with my grandparents for my childhood and teens, and even went back to look after my granddad when he wasn’t doing so well.  I took a job locally at that time in case there was any urgent need for me to go home.  He hadn’t asked for this, but it was something I believe he truly needed.
The same goes for my wife; living with her grandmother was a very similar situation and we learnt that people often require more help than they ask for.  What gets in their way is a sense of pride; the protection of their ego from damage.  The desired result being to avoid shame.

This is something that goes for everyone.  You, me, the next guy.  This is not just behaviour limited to the elderly and those set in their ways, but everyone.

For Agile teams, there can’t be a fear of approaching each other for help.  As a developer, the pride you have should be in your work; there is no room for an overinflated ego in any individual because the whole team gets affected by this mindset.  There is no shame in asking for help because it resolves issues, results in efficiency and learning.  In addition if you are practising Scrum and have a Scrum Master, or an Agile Delivery Manager outside of a Scrum environment, use them!  They’re there to make your lives easier, to protect your time and allow you to free up as much of it as possible.

Don't be afraid to ask for help!

I cannot stress enough what the human condition is.  We are interdependent as well as independent.  We can get on with things but we need to know it’s okay to rely on some people for certain things.

How many of you grow your own eggs, cut your own meat, make your own phone batteries? Hardly any I’m sure (especially the last one!).  We rely on others all the time; it’s a given.  Why not extend the same philosophy to those who are there to help you in a professional capacity?

Above all, it takes strength to ask for help, but it’s there for you if you need it.  I know I keep banging on about developing a cross-functional team, but that is the aim.  Self-organisation and becoming cross-functional are results of the trust you have in your team, to be able to approach them, and help them in turn.

If you have a team which operates in this way, the pride is shared.  The work speaks for itself and the unit is credited as a whole.

The team that marches TOGETHER makes the loudest and the most impressive nosie...

 

Getting the culture right from the get go…:

I spoke to someone last week at the fantastic Agile Coaching Exchange meetup, this time the topic being on ORSC tools such as Design Team Alliance (DTA).  When exploring the culture of sharing responsibility, dealing with emotion during difficulties and avoiding blame culture, it was noted that some companies these guys worked for had asked that individual team members be evaluated and monitored for their individual efforts within the team.  This whole concept seemed double-edged.

Whilst you’d imagine and expect team members to pull their weight, it is not up to management to try and weed out weak links.  It is up to the team to be self-organising; they must put an end to poor effort by encouraging and helping their team members to realise their potential.  The root of the problem must be found and worked on.  The weak links must be developed into stronger links where possible, because that process is a hell of a lot less disruptive than getting a new team member in in most cases.  Sure, there are times when things may just not work out, but then the team may have been flawed from the start, and the culture may never have been set in place.

The DTA approach is excellent for setting a culture in new teams and introducing new team members into an existing culture, allowing it to be revisited and improved to incorporate the new team members’ input.

You can use this to get an open, trusting culture from the get go.  You can see the slides from the ACE meetup on June 19th here.