Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo descriptionKnow our brand.
It’s clear that everything agile is trendy. If we put some post-its by the office, we do some cool dynamics with legos and copy something from the Spotify model, customers will fall at our feet and we will also have free ways to develop comfortably, without dates or a closed scope.
Well, this does not work like that. In most cases, both customers and developers are not clear on what it really means to follow the principles of agile development.
On the one hand, it is true that many customers are attracted to this type of practice, as a sign that they work differently and that, perhaps, for once, the development of the new product is not going to be a disaster, outside of scope, with extra costs and without adding value.
However, they are still reluctant to fully trust the good intentions of those who, so far, continue to see as their suppliers.
On one occasion during a meeting with a client (whose name I do not want to remember...) I even heard that agile was the best way to spend money without knowing on what, without control.
On the other hand, as the saying goes, "clothes make the man". Being agile is much more than post-its and throwing us to the ground to play with legos.
In fact, the implications in terms of responsibility and commitment are such that any developer should feel intimidated to say the least.
You are no longer part of a chain, you are not responsible just for your lines of code or your designs, you are responsible for the complete result to be what the user expected and, in a certain way, for the benefits (or losses) that your client will get from it.
Being agile is not a way to make life easier for software companies, nor for customers to have flat rate changes. The biggest advantages are for the product itself and the business.
What we are sometimes not aware of (neither are they) is that agile is not about comfort, it is about value. As with almost everything, you have rights as well as duties, its not all an advantage. You have to work more, you have to be available for everything, you cannot isolate yourself in your tasks, you owe it to the team, to a common goal beyond "fulfilling" your part.
The goal of an agile team is to achieve the maximum performance of the team in order to achieve the best possible result. To achieve this you can do anything except relax and work at your leisure.
Business and development must work hand in hand, challenging each other and leaving their comfort zone, to ensure that the best decisions are made and carried out in the best possible way, with team spirit and collaboration. And this is more difficult than it seems, for both parties.
In the end it turns out that the silos that are talked about so much in digital transformations are more comfortable and comforting than one might think.
For most of those who make business decisions, the ideal scenario would be to be able to abstract from the technological complexity where they lack mastery. Similarly, for developers it would also be easier not to have to deal with product owners, stakeholders, their interruptions, their urgencies and their market figures, but to focus on technical innovation, which is what they like the most.
The problem is that it is proven that in this way value is not generated, that the lack of communication and collaboration is devastating for the business in the digital world, that the breakdown of silos and the change in the relationship models between customers and technology partners (yes , partners, not suppliers) is essential.
If we look at the values of Scrum (the jewel in the agile crown), if we look closely,it is far from easy: they are very ambitious, they involve a lot of work, a high level of personal demand and a change of mentality for all , business and development.
The challenge of adopting a form of agile work is not to change phases by sprints, nor reports by reviews. The real challenge is to live day by day with the values of commitment, focus, openness, respect and courage, to make the pillars of transparency, inspection and adaptation a reality and to make trust a reality.
I would like that when clients and developers read this personal reflection on what for me is the essence of being agile, they will take away two simple ideas:
From now on, let's not underestimate the agile development as a trend that borders on the hippie culture. We value that, those who really get on-board are willing to stand up, roll up their sleeves and do everything necessary to add value and go one step further.
"What we do in life… echoes in eternity", Gladiator.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.