Agile Barriers

Geetha Ramachandran, Scrum Master | Agile Transformation Coach

"What separates me from my present is like a fine mist, an intangible veil, an invisible wall. They don't put up the slightest resistance. Nothing would shatter if I were to walk through it. Because there is actually nothing at all between me and the world. A single step would be enough. Why didn't I take it long ago?" ― Pascal Mercier

Have you ever wondered why someone was resistant to change? Or why someone wouldn’t go any further? In an Agile team or organisational context, this could be certain team members, stakeholders, managers or executives.

As a Scrum Master and an Agile Transformation Coach, working with different teams, I have often recognised, that the team or organisation has out of its own free will, imposed a glass ceiling or glass wall on how high or how wide they can or want to go.

If successful in applying Agile ways of working at a team level, they are delighted by the structure, the efficiency and the team bonding it gives them as a team, be it Scrum or Kanban or any other Agile framework that has been done well. But stop at that point that they ‘wanted to get to’ not realizing they had raised for themselves invisible barriers to go any further. Or sometimes, if not successful, did not get to where they wanted to, because they were limited by their beliefs.

Working with multiple-teams as Scrum Master and Coach, in a high-touch-low-touch combination, gave me a rich experience of different teams, organisations and personalities. I take a sample of 3 teams out of 10 teams I worked with in the past few years, to share my observations. Low-touch or High-touch was decided by how much support the team needed to make it self-sufficient or as we say self-organised.

For each team, I state who they are, what worked well, the barrier and what could be done or was done to help. In this sample of teams, no criticism is implied, merely observations, aimed at helping teams and organisations break these barriers down.

Team 1: Low-touch team. Initially started as a group of talented ‘individuals’, blended into a team, especially brought together by the retrospectives during the year I was with them. Senior members set a great example to the team with their pride in quality and aiming to achieve 100% sprint goals. Coaching senior management and stakeholders along with the product owners on backlogs, release planning and change management, kept the team going in its momentum throughout.

What worked well: As this was a small company fairly new to Agile, arranging for all team members to represent their team in turn, every week, to meet the CEO and share what they achieved in that sprint and what they had learnt from their retrospective gave them pride and made them ‘want’ to do well.

Barrier: Where this team had any dependencies on another team which was not as high-performing as them, they could not understand it, They raised glass walls around themselves and didn’t reach out to help the other team get better.

Ways to Help: I left the organisation at this point, but what would help in this case, would be not only to have ‘team’ or ‘product’ goals to be reached but also ‘organisational’ goals to be reached and rewarding them for reaching such organisational goals.

Team 2: High-touch team. Senior most member wanted to be known as a high performer and had difficulties giving out information or assisting junior members get better. It took some effort to encourage him to ‘allow’ other members to do Sprint or Release demos or to let other members speak if they had a differing view.

What worked well: The first step which was a huge help was to create a sense of equal importance in the team. I created a Strength Profile workshop for this team so they could understand the strengths of each other.

Barrier: Fear. The younger team members feared the senior member as he was close to a chief executive in the organisation.

Ways to help: Getting the chief executive engaged and to recognise the strengths of the overall team evened out the playing field. Also creating opportunities within the wider organisation, i.e. outside of team and product for other members to shine, ensured they developed more self-confidence. When one of them was encouraged to run a Code Dojo across teams, he did a great job of it!

Team 3: High touch team. This was an API team with some very intelligent and very strong characters in the team. They used cutting-edge technologies to build a super-fast API, forgetting that what they built must integrate into a slower product ecosystem. Senior members also did not believe in ‘frivolous’ sprint ceremonies like retrospectives or the need for the whole team to come on board. Or even the importance of catering to the wider product. One of the toughest teams I have worked with, which when aligned, also gave a greater reason to celebrate.

What worked well: A few new members were recruited who had passion and courage. They were encouraged to question ways of working.

Barrier: Building a wall around their ‘section’ of the product. This was a classic case of building a super-fine engine for a wooden wheel carriage. May give the engine builder pride but doesn’t do the carriage any good.

Ways to help: There were many ways to help but some key points. First, this needed removing team-silos. More inter-team interactions and inter-team presentations. Second, this needed a stronger technical oversight and integration test planning at an organisational level. Though the organisation decided to continue this as an ‘API team’, thought was also given to how else product teams could be structured and organised to avoid this in future.

When I trace the success and the extent of success each team achieved, I am fascinated to see a pattern of barriers emerge.

Pattern 1: Team vs Organisational Transformation. While to begin with, we had to focus on specific ‘team’ based improvements through Agile practices, it does not start and end there. If we operate from this limiting belief, we create glass walls between teams and ceilings within the organisation. Agile practices need to transform not just single-teams but the whole organisation. This needs driving and breaking walls both from the top and from the sides.

Pattern 2: Values vs Product. Often, what makes or breaks a team or organisation is not their ability to excel technically, but their ability to work together. Basic human qualities like courage, openness and transparency must be fostered. Organisations need to be clear not only what their ‘product’ vision is, but also be clear on what their ‘value’ vision is. Having a value vision ensures that product vision is reached.

And by the way, it is not one vs the other, it is one leading to the other.

While what I have said here is not new, seeing this happen repeatedly means something.

Get in touch for a chat to discuss barriers and patterns that you may have observed in your organisations. Together we can create better strategies. I can be reached on LinkedIn.

Geetha Ramachandran

Scrum Master | Agile Transformation Coach

https://uk.linkedin.com/in/geetharamachandran?