What is agile development

Scrum, Kanban, Jira, Trello... are not synonymous with agile development. When talking about agile development, it is important to clarify concepts to avoid misunderstandings. Agile development is based on the values expressed in the Agile Manifesto (https://agilemanifesto.org/):

• Individuals and interactions rather than processes and tools.
• Working software rather than exhaustive documentation.
• Customer collaboration more than contract negotiation.
• Responding to change more than following a plan.

These principles make it clear that processes and tools do not in themselves define an agile approach, but are only a support for it. Let us examine each pillar to better understand its benefits.

Individuals and interactions rather than processes and tools

How often, after a problem resulting from a lack of communication, do you hear: 'I had sent an e-mail explaining everything' or 'I had written it on a card'?

Mails, tickets on Jira or Trello, messages on Slack or Teams are just tools to convey information. But a process, however well defined, must be based on a culture of confrontation and interaction. Otherwise, instead of making work efficient, it runs the risk of becoming an alibi for de-empowerment.

Adopting Scrum or Kanban practices does not guarantee an agile approach. A retrospective every fortnight, without a real culture of feedback, risks only generating bad feelings and misunderstandings.

For a true agile approach, a climate of listening and confrontation must be created, allowing people to talk freely to each other, share opinions and ideas. The working process should be established by the team, with the possibility of testing, analysing and refining it. Responsibility is taken collectively.

Working software rather than exhaustive documentation

The main difference between an agile and a waterfall approach is the continuous release of working software, collecting feedback as quickly as possible. The faster the feedback, the faster one can react.

Relying on documents describing how a software should work is not as valuable as obtaining feedback directly on the software itself.

Beware, however: this does not mean eliminating documentation. It is useful for explaining why certain choices are made, defining workflows and providing a basis for discussion. However, in the end, what really counts are the functionalities present in the software: those that customers and stakeholders can see, use and evaluate.

A further step would be to evaluate not only the functionality of the software, but also its concrete impact on the customer's business. This would involve defining metrics to measure the added value of the software in solving real problems. Sometimes the time elapsed between the release of the software and a visible impact on the customer's business can be long enough to prompt the definition of intermediate metrics to certify the direction taken.

Collaborating with the customer more than negotiating contracts

Do you really want to spend time arguing with the customer about what was included in the contract and what was not? Whether a detail is a variant or part of the first version? Wouldn't it be more useful to focus time and energy on finding the best solution and the path to it together?

The contract is necessary to establish the rules of collaboration, both with external customers and with other internal teams. However, defining everything in detail from the very beginning can make the process rigid and difficult to adapt. Every change would require a variation to the contract, slowing down the work and reducing flexibility.

Better to adopt contracts that foster collaboration, allow for adaptation to change, and facilitate smooth and responsive work.

Responding to change rather than following a plan

If we have to reach a restaurant by a certain time, it does not matter which route we take if it allows us to reach the goal. We will certainly have defined a route in the beginning, but if on the way we encounter an accident or discover that there are works, instead of getting stuck in traffic, we will have the navigator suggest an alternative route to the restaurant. Changing our plans according to the context to achieve a goal is something we do all the time.

The initial plan is defined in the moment of least knowledge of the problem. If our goal is to solve a problem, the work itself will provide us with new information to find the best way.

Rigidly following a detailed plan only makes sense if the conditions remain unchanged, and in a complex world this is impossible. In a dynamic context, on the other hand, it makes more sense to be ready to adapt to changes without losing sight of the final goal.

Conclusion

Agile development is not a predefined framework, tool or process. It is an approach that values collaboration, rapid feedback and adaptability.

To be truly agile, it is not enough to adopt Scrum, Kanban or other tools: it is necessary to create an environment in which people can interact, share responsibility and adapt to change effectively.