Introduction
We are Agile! We have a team in a room, we do dailies and retrospectives! We have a product owner, scrum master and sprints! We write user stories e have acceptance criteria!
Wow! The department manager proudly claims that his teams are Agile and they are in a very advanced level using this way of working.
Indeed, at first glance, it may seem like a case in which any company would like to mirror themselves and aim to reach the same level of excellence.
Making a parallel with everyday situations, have you ever noticed yourself re-evaluating a product or service after gaining more knowledge about it or its process? For example, anyone who has gone through the experience of buying inbuilt furniture, which looks beautiful exposed in the store, but after you purchase it, the ordeal begins, with delays, non-standard furniture, that doesn’t fit or is not measured correctly for installation, etc?
For those who have little knowledge about a subject and/or have not experienced it, their observation of certain details and possible problems is limited, precisely due to lack of knowledge and/or lack of experience. The person is delighted with what he sees exposed, but by having closer contact and usage of the product or service he purchased/hired, he can perceive numerous details and problems which were not apparent at first.
Analysis
This can happen with various products and services, and Agile is no different!
Although there are many good Agile examples, there are also many bad examples. One of the most common is what we call Using Agile Just for Show.
At first glance, the environment impresses, all teams seem to use state of the art Agile, making use of the frameworks, practices and tools according to the recommendations.
However, looking more closely, spending time with the teams and asking some questions, we begin to notice that everything is just for show. The goal is only to show others that Agile is being applied, but the Agile benefits are not being reaped. Why?
Revisiting the Agile Principles
Do you remember the Agile Manifesto Principles? http://agilemanifesto.org/principles.html
It’s no use having the open office space, with boards on the wall, post-its stuck on them, co-located teams, meetings and practices being performed if none of the principles are being followed.
What comes first are the principles, and on top of them, we find ways, practices, and tools to achieve the reality proposed in each principle.
- Is the customer actually having continuous and advanced delivery of software (or other product/service) with value?
- Does the team respond quickly to changes in requirements?
- Continuous delivery is a reality in the company?
- Are business people really part of the team and available?
- Are teams motivated and have decision-making autonomy within their knowledge domain?
- Is the daily a real communication moment or merely a ritual hated by all?
- Are working software/product/service deliveries frequent?
- Is there a sustainable pace of implementation in the development flow?
- Are teams not run over when they want to do the job with technical excellence and design?
- Is everyone free to propose changes to maximize simplicity at work?
- Are teams free to self-organize to define architectures, requirements, and designs?
- Do retrospectives result in actions that are implemented to make the team more effective?
