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.



Meeting a nay-sayer voicing concerns about Agile…

A very interesting opportunity presented itself to my last week.  On a Friday night, I was out helping my wife celebrate the end of her ACCA exams for the summer where I bumped into an old friend of my sisters, who was intoxicated, out celebrating his birthday.

He was a guy who manages teams of project managers and has seen adoption of Agile add little to no value to the teams his project managers have worked with.  When I cut through all of the negativity he was throwing out there, it was clear what the source of the frustration was.  There was so much focus on following the Agile methodology whenever his teams went about it, they forgot some important things along the way.  Who knows who they were trying to please by “doing Agile” stuff, but by getting bogged down in processes and tools is against the first value of the Agile manifesto.

What was causing the frustration was simple.  No-one was getting on with the work itself.  The team wasn’t becoming self-organising and cross-functional, nor were they being guided or empowered to do so.

He brought up an interesting comment when I explained they need to think in business terms:

“If the developers were thinking in business terms, they’d go and start their own business”.

Not all projects are suited to having an independent business.  These projects are necessary within businesses themselves and require developers who are super-talented and can think in business-needs.  It is short-sighted to think of developers in this way.  Without the necessary respect for the amazing talent out there, how can you motivate and expect the work to get done?

You see, on the flipside of the processes and tools is the thing we value more: Individuals and Interactions.  I have a feeling his project managers don’t quite see it that way.  Being Agile doesn’t come about when there is no respect and that’s something that needs to be addressed if we want to get better at what we do.