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.

 

Advertisements

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.

Agile or FrAgile?

I haven’t been a Certified ScrumMaster very long though if you meet me you’d think I had been.  Maybe it is because of my limited exposure to traditional waterfall projects that’s been my saving grace; I agonise at the thought of a project that makes the day to day grind seem like wading through sludge for the development teams.  If you, like me, have a goal in mind you want to swim as fast as possible to that goal.

What do roadblocks lead to?

On my journey through various roles in various companies, I have come across so many projects which have hit various roadblocks along the way.  The only way I have been able to circumvent disaster is to ensure adaptation and flexibility was at the forefront of the minds of the talented people executing the projects.  Be it authoring custom business intelligence reports or producing an eCommerce website, all projects have so much room for improvement.

Being naturally Agile…

This naturally led me to adopt Agile principles without ever having formalised the approach; working in an Agile way made sense to me.  No, I didn’t have Sprints or Daily Scrums or any other artefacts and activities defined when I started off; I didn’t know about these as such back then.  I was not a scholar of XP, Kanban or anything of the sort.

What made the way I worked Agile then?  I’d say it boiled down to:

  • Being part of a team that was self-organising, that I could respect and trust
  • Being transparent if things were not going according to plan; communication is key
  • Focus on getting the projects delivered to client satisfaction
  • Being flexible

Missing the point is messing it up.

I have friends who work for large governmental organisations and various other companies where legacy systems are in place and it’s insane how so many businesses are resistive towards the changes around them.  Even those which are actively pursuing change start waxing lyrical about their move into Agile, but are walking head first into what I believe is a trap.  The trap is that they think engaging in Agile activities, such as daily stand ups, will be the be-all and end all of getting them working more efficiently.  They actually end up reducing efficiency my friends ensure me.  Agile used only on the face of it is probably more of a pain than it is a tool.  This is because Agile is bandied about as a term and treated as magical solutions to all their problems.  It is not.  It is supposed to be a way of being; a set of principles that should be followed.  The activities and artefacts are a means to an end, and that end is covered in The Agile Manifesto so simply.

Where can I find that missing magic?

It’s in the Scrum Development team.  The team needs to be respected, trusted and encouraged to become self-organising.  It’s tough, because in a lot of cases management don’t understand how to be Agile, nor are they committed to the processes required.  This requires something bigger than Scrum alone to tackle which we will talk about later; Scrum is simply a framework for getting potentially shippable iterations via Sprints; the teams within this will provide the missing magic you need once they are a stable team that works efficiently.  The Scrum Master’s role is to facilitate this whilst protecting them from extraneous requests from the Product Owner and others.  At the same time transparency is required for trust to develop as well as individual team members’ confidence levels and skill sets.  Working towards this develops a team which is Agile, not just practises the activities.

What’s “being” Agile like?

Daily Scrums become second nature, Sprint Planning becomes realistic and achievable and the Sprint Review in turn yields an iteration which hits that definition of done.  Teams become proud of their work and that they have set out realistic commitments which they then stick to and deliver upon.  Planning Poker sounds less like a game over time and becomes a valuable tool for gauging what can and cannot be committed to in a Sprint.  On the flipside, fun increases.  Team trust and understanding increases and the members of the team edge closer to being truly cross functional.  Individuals pick up skills whilst working on various Sprint Backlog items and in turn use them in future sprints.  Each team member becomes more valuable daily.  Impediments are tackled easier and the increased communications means the Scrum Master is truly in the loop and helps the team out.  In turn the development team begin to understand business needs in business terms; as they become ingrained into the company; they begin to understand the Product Owner’s needs as a champion for the end users.  That’s the ideal anyway.

Management still don’t understand…

Any company can have multiple teams.  The problem we find is when teams turnaround or outsourcing occurs regularly.  The ideal scenario is to have teams who know the company, understand the product vision and critically, are still around once a project is over.  If they can then be used on subsequent product development the teams are much more valuable.  In fact, having multiple teams is a realistic scenario which needs a larger framework to scale Agile into larger enterprises.  There are many approaches to this developing and in 2014 you’re seeing some big schools of thought about to shout out about this, the most notable of which is Dean Leffingwell’s Scaled Agile Framework (SAFe).  Overall understanding and appreciation takes time and results.  Scrum aims to deliver results in product increments to the minimum viable feature set.  A good Scrum Master will facilitate the continuous improvement required by the teams to get to their potential and in time truly being Agile at the smaller scale will result in an easier job scaling it.  Practising Agile activities and having Agile and Scrum artefacts without truly utilising them as they are meant to be used will result only in inefficiency. This is what I refer to as being FrAgile.  This is why management, in those cases, will never understand.

Continuous Improvement is key

Striving for improvement is the aim.  Improvements in quality, speed, processes, output.  The self-organising team will aim for this.  They will be protected from interference during a Sprint, but be able to adapt and be flexible for subsequent Sprints.  They will have enough respect to be listened to if they give their opinions of what can and cannot be done during a Sprint.  They will be trusted to get on with it and expected to communicate if they have impediments.

We’re all human; we want to have fun, we want to enjoy life.  We also want to be recognised for our efforts, to be respected and to be trusted.  This goes for the amazing talent behind so many development teams.  It’s their continuous improvement that is key for a very good reason: without it, agility becomes fragility.