This section of the Agile series is going to run through some of the most common buzzwords and potential pitfalls we see on a regular basis when we look at agile ways of working. The core values are simple but it can get complicated when terminology overrules principles.

When we see teams who do regular standups but don’t know why they do it, it’s very important to make sure they understand the reason why they’re doing it. That’s why I often refer to the Agile manifesto when I work with different teams: Software Delivery or DevOps. I stress the importance of core agile values so that the teams understand the benefits of the things we do. Creating a collaborative environment and platform that can be used to share daily work progress, achievements, as well as bottlenecks is more effective than waiting for a weekly or even bi-weekly meeting with the whole team.

For example, a daily standup is a form of collaboration and a very important aspect of adopting agile ways of working. It’s an easy way to start changing the behaviour of a team so they learn very simple techniques. Sprint planning or a retrospective session is another way of planning collectively and reflecting on the work the teams have done during the previous sprint.  Even though it sounds simple and perhaps most of us already do these things, it’s not enough. We need to understand why we’re doing it and what the benefits are so that everyone buys into a new way of working and agile words don’t become buzzwords.

When a Scrum Master sees their team organising a daily standup without the Scrum Master’s help to facilitate this ceremony, it’s not sufficient to say that the team is self-organising. A self-organising team is a team that is empowered to make decisions, track their progress, change their process if they identify inefficiencies and even design the team and organisational context. However, this term is very often used without taking into consideration its full meaning and the whole context.

Another example is a Sprint Review meeting or ‘Show and Tell’ which we organise every Friday at Automaton Logic. As Simon Sinek says we need to start with ‘Why’ in order to understand the real value of the Show and Tell which is to build collaborative working relationships and communicate feedback and progress with senior stakeholders as well as other teams across an organisation. It’s important to encourage developers and DevOps engineers to talk about their work even though it’s not perfect or fully completed yet.

At our Show and Tell sessions everyone feels very engaged and business stakeholders really like meeting the team to see the work in progress as that’s the best way to mitigate any risk. It’s also very motivating for engineers who can ‘show the thing’ they’ve been working on and talk about the challenges they’ve come across.

Nevertheless, it takes a lot of trust to work in a collaborative way which is not always easy to begin with but I believe everyone in an organisation can take small steps and contribute to building trust. A small step to start with is leading by example, you don’t always need to say ‘this is an environment where everyone can speak up and feel psychological safety’, but you should be able to feel it, staff should never be punished or judged and all opinions should be welcome.

Servant leadership is an important element of an agile culture. It is also something that has fallen trap to becoming a buzzword, and usually people think this is a responsibility of a scrum master/agile coach or agile delivery/project manager to be a servant leader but actually, anyone in an organisation including any manager or any other role should act as a servant leader.

As Stanley McChrystal says: ‘A servant leader must give way to an approach as a gardener, enabling rather than directing. A gardening approach to leadership is anything but passive. The leader acts as an “eyes-on, hands-off enabler who creates and maintains an ecosystem in which an organisation operates.’

In many traditional organisations, managers usually tell the teams what to do or how to do it. A servant leader does exactly the opposite. He or she wants the team to decide how they are going to deliver software or solution. Moreover, it’s not only about delivering a product and working out how it will be built, but also what process they want to follow or what agile method they want to use.

A servant leader is a coach who may provide guidance but never give instructions. He or she asks a lot of questions to guide a team in the right direction and to find an answer to their questions. For example, I’ve found out recently according to a survey that coaching skills are the most sought after skills for any management position in business nowadays as organisations want to have managers who can coach teams and help them become high performing teams.

Agile is a buzzword within itself. It’s very interesting that ‘Agile’ is just meaningless. We can talk about agile ways of working, agile projects management, or agility but not ‘agile’ or ‘doing agile’. I think we should speak about agility more often: how the teams can leverage agility, and learn that it’s about agile values and principles rather than process or daily standup.