By Ana Brenes (ERNI Switzerland)
In the final chapter of the Triple-A Saga, I will be talking about the word “agile” and what it means to me. Of course, it will be in the context of architecture, and I will also introduce to you its connotation to the enablers, the architects.
Abstract
As in every good Saga, there must be a conflict. This is not to say that there wasn’t enough potential for conflict in the previous elements.
You may ask now, why a Saga? Well, I think it is very fitting for the subject and the purpose of what I wanted to convey. The meaning of the word saga is “what is said”. And here is what I think is very fitting. I brought you with me on a trip, the trip of the Triple-A in the Digital World: Architecture, Architects and Agile. At the end of the Saga, I will give my opinion of three concepts that accompany me every day which are very important to our digital world.
The last part of my Saga is about the word “Agile”, what it means and represents for me and what indeed I do not mean by it.
I think there is a lot of good and bad behind this word. Unfortunately, as is the case for a lot of “things”, “things” are not inherently bad, but they can be used for good, or they can be used for bad. Primarily if their nature is not understood, the context in which the “things” are used is also not understood, or if the people “using” them do not have the best intentions.
One thing I can already tell you is that this is in no way an indictment of the Agile Manifesto or any “practice” used to develop software in our digital world. Yet I will give my opinion about some of these methodologies based on my experience.
I believe it is more about a “state of mind” or even a “conviction” than anything else. This should be an important aspect for a practitioner who has the fundamental responsibility of creating and enabling the “Architecture” and has the role and duties of an “Architect”.
Agile: The beginning and an opinion
The meaning of the word Agile in the dictionary is straightforward: “able to move quickly and easily”. So far, so good; for me, this is a good thing. We believe this to be a positive when we think of anyone or anything having this attribute or property. For example, if we see the following two pictures, we can think they are good examples of agility.
Then we have the “other definition” that came to be what has been known in the last 20-some years as a new definition for the word agile: “relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans” (Oxford University Press, 2022).
When considered in this way, independently from any interpretation, it could also be a good thing.
This new definition is known as the concept that originated from a group of people trying to find a better combination of different methodologies and practices that would serve their purpose: develop software successfully (AManifestoGroup, 2001). In the end, that shall be the purpose of any “methodology” used for software development.
Over time this “idea” has been used to create practices and frameworks that try to implement it in different ways and under modified premises but with the same goal. The goal is to bring the adequate and needed software in the shortest time possible and with the least amount of money.
Architecture and Architects must work in the context of the available framework or methodology (for example, the SAFe framework or the Waterfall methodology, to mention the opposite sides) to get things done in an organisation. Often they are different people than those selecting the method to be used; it is decided by someone else in the organisation.
Here is where I think it gets a bit messy and questionable. Over time, many methodologies and strategies have been created and used to develop software. It is known that all of them will impact an organisation in one way or the other.
And we know things can be good or bad or can be used with good or bad intentions. Sometimes voluntarily, sometimes driven by circumstances. This is what has happened with the development of software and the methodologies created in the last few years. Many ideas have been discussed, documented and practiced, and in many cases, they have yet to be understood or have not been used as intended.
I think that people having strong opinions and presenting challenging ideas is good, but the problem comes when people do not try to find what is best for the business that they are responsible for, but instead they want to be right. I understand our main driver as humans is survival. Still, I think surviving in this new world has very different connotations than what was the case many million years ago. If we use our intelligence and smartness to make great things, then we can and shall also use them to make better things and decisions.
In my many years of experience, I have had the chance to experience different methodologies for implementing software. I have seen companies with different methodologies having success and not so much success. I was successful using a “modified” waterfall methodology to develop software, and I have also seen some “modified” agile methods to develop software that was “more or less” successful. They were successful not because we used this or that methodology but because of the people doing it, taking care of what needed to be done and doing the right thing.
All in all, not understanding and not adapting to real needs is the actual formula for failure. The main point is that each methodology needs to be clearly understood for what it was made for and must be analysed. Any decision made as to what to do should be made by the subject matter experts and not “managers” or people who do not understand the subject matter.
In general, the key to any organisation’s success is knowing the nature of the business, knowing why they are doing it and then finding the strategy that helps them achieve it. Of course, this is easier said than done, yet very important. The essence lies in finding the strategy that supports the organisation in achieving its goals while considering the facts and not engaging in wishful thinking.
Since the world runs at a much faster pace than before, it is unrealistic to expect to be able to make all critical decisions upfront without having to adjust them as time goes on. But the key to this is identifying the real essential decisions and how to go about them. I think that flying blind, which amounts to me assuming to know what lies ahead and expecting it will all work out well, is not very responsible. It is never going to be a formula for success in an organisation. If a person who has no responsibility for anything or anyone other than himself lives on a day-to-day basis, this may work out and be good for him. But for the rest, there need to be informed decisions if something needs to be achieved.
Part of my “disconcerting feelings” with Agile methodologies is the handling of Architecture in their framework. In some cases, it was left to the mercy of developers to be done somehow; in other cases, it was left to the organisations to develop some strategies to ensure that architecture was done – but without thinking that it might cause problems down the road. Later, it was somewhat integrated as part of the framework, yet for me, this does not resolve all the potential risks. We can see in practice, when the framework implementation takes place, how there is so much conflict and uncertainty about responsibilities and who will do what.
Let us take a little detour into another industry; for example, where Lean Thinking comes from. If we were to make cars without a good idea (architecture) of what the result, in the end, shall be, would we think that a good car would be built correctly? The thing is that the effort and time needed to come up with the “architecture” were put in beforehand, and since mass-producing cars does not require integral structural changes regularly, the architecture supports another kind of changes without having to change the essential way in which cars are made.
Another “disconcerting feeling” comes around the lack of some business plan or realistic goal of what shall be done in a given period and with a reasonable amount of money. After all, money does not grow on trees. Organisations do not have endless resources, and they will die if they are not economically viable. Unfortunately, the financial world is very creative, and many organisations have been able to find “alternatives” to hide or overcome bad decisions, yet that does not mean that we shouldn’t try to do our work in a meaningful economical way.
I do not profess that we should know every little detail from the beginning or build something that will not allow for a change in the future, since it is the nature of the world to have constant change. Yet some general direction and guidance are required.
Hence, having an Agile mindset and an open attitude is the key to success. To achieve something, we must have a vision of where we may want to go and what we want to achieve. Structure and order are also needed; this looks like a plan to me. Still, keep in mind that the world is constantly changing, and we shall need to adjust as we go. This is the mindset I am referring to.
To be agile means to move quickly and easily. That is what we shall strive for – finding the actions, strategies, tools, processes and whatever is needed to move as soon and as easily as possible. But with a purpose and a direction.
For me, having an open attitude means to understand that today we may decide on one thing, and in the coming weeks, we may need to change it and that it has consequences. We may only sometimes have the required or adequate information to decide. Hence, we need to be prepared for change and adjust any decision. Also, being open means making sure that communication always takes place; all relevant people should be aware of what is happening.
Only in some aspects of the domain or business will there be constant change; there are quite some stable areas. Others are very volatile and unstable. Others will require compromises to be made. Here is where the experience of the practitioners shall serve its best purpose: identifying based on experience which parts are volatile and which are stable.
Depending on the organization and culture one or the other framework is best suited, but in the end not every detail and every framework is best for a given organisation. Organisations exist in different cultures, and what works in one may not work in the other. This is also another aspect to consider when selecting methodologies. Today organisations are made of people. Many organisations are thriving. But what is real success? This concept shall be analysed and discussed, but I will not address it here.
My point here is that I consider Agile more about a mindset and attitude than a particular framework. This concept goes hand in hand with what is needed in Architecture and by the Architects: to be enablers, to help with the unknown and to guide and help produce value with what is done and needs to be done.
References
AManifestoGroup. (2001). Agile Manifesto. Retrieved from Agile Manifesto: https://agilemanifesto.org/
Oxford University Press. (2022). The Oxford Languages. London, United Kingdom.