Agile, Scrum and DevOps – Promise vs. Criticism

The Agile Principles on meetings say that: Business people and developers must work together daily throughout the project. And: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

In Scrum meetings are called “events”: Daily, Refinement, Retrospective and Planning. What are they for? They allow you to focus on a specific aspect of the delivery. The entire team’s attention is directed towards a specific task, such as estimating the workload, reflecting on how the team has been working recently or planning the next tasks. Their regularity helps maintain a routine and a steady work pace.

If they are conducted wisely, daily meetings can improve communication. They should not be just 15-minute sessions without deeper focus. The Scrum Master plays a key role in maintaining these events, acting as a skilled leader who covers the cross-section of the team’s tasks and skilfully ties up the loose ends.

Sometimes a company or a team will give up on a meeting, assuming that "everyone knows what to do" or "everyone knows what problems we have". Often that is not the case, as people might be focused on delivering their part. If we don’t give them the opportunity to see the bigger picture, more problems will arise.

Yet again, let’s read what Agile Principles say about communication: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

It is short-sighted not to recognise that the tasks that are performed in the project and their level of advancement change daily. Given our scope of duties and the goal we are aiming for, we should communicate often to achieve it.

Moreover, assignments are intertwined with each other. Keeping information that concerns the whole team to yourself is selfish and harmful to the entire project. The total product is made up of the work accomplished by individual people, but it is not simply the sum of its parts.

Talking about our work enables us to reflect on our own tasks, take a step back and consider what we are doing and why. Additionally, the whole team gains a comprehensive understanding of the tasks they are performing, which will pay off in the future in the form of faster decision-making and the ability to identify issues in the process.

The Scrum team is cross-functional by nature and consists of both business and IT members. In the insurance industry, for example, it might include claims adjusters, underwriters, developers, a product owner and a Scrum Master. This combination eases problem solving and speeds up the flow of information. However, it also requires from team members to be willing to reach a consensus and have good communication skills.

Interpersonal communication can be difficult and very stressful for many people, increasing mutual distrust, vigilance and a natural readiness to defend oneself. However, this does not release us from our obligation to show mutual respect to colleagues and clients. The team must give each other space to celebrate success, but also to address problems when they arise.

How we embrace them is up to us. Reflecting on what went well and what went wrong gives us an opportunity to learn from our experiences. Checking the mood of the team and clearing the atmosphere is equally important, which in turn leads to team building and improves our performance.

Agile is all about communication. It’s not easy. Implementing this way of working does not happen overnight. It requires skilled leadership, commitment from both superiors and employees, and constant practice.

Experienced Agile teams do not abandon daily meetings or ongoing summaries just because "they already know how to do Agile". They still meet because they recognise the interdependencies between their tasks, and they respect their colleagues and their work by providing them with what they need.

It’s easy to conclude that "Agile has failed" when something stops working. But before we do that, let's consider whether we really understand the principles of Agile and whether our organisation allows us to be agile.

You can dismiss a challenge by saying "This is not Agile", but such a summary solves nothing. You must look at the problem, try to analyse it and draw conclusions.

We should be open to constructive criticism and discussions about Agile, Scrum and other work methods. Conversations provide an opportunity to surface and identify problems that employees struggle with… daily.