Skip to main content

In this time period, almost all organizations, regardless of the sector and the department we work in, have already met the concept of “Agile” and adopted it as a methodology; has added its visions to establish this structure especially in IT strategies. It would not be wrong to say that the teams that adapted the fastest to this transformation process are from the software world. Today, we as the business analysts who play a role in the software matrix today, and project managers, IT managers, product managers, software development teams and, all the business units; in every conference, workshop, and event we participate in, we try to understand and make sense of Agile. The consultancy support received by the companies and in all the training given to the employees, the framework of Agile is emphasized. While doing this, there is something we should not forget; that is to explore more deeply instead of memorizing Agile methodology concepts, popular and trendy words, and activities! When I am thinking about this matter, I remember a quote from Richard Feynman: “Knowing the name of something doesn’t mean you understand it.” So let’s take a look at what is not “Agile”, which is not discussed much today.

If we start from the most fundamental structure, “Agile” in an organization is not only a method and a way of doing business that IT teams will apply! Adapting the approaches like XP, kanban, scrum to IT teams will leave the transformation chain incomplete. To create a product fast, to catch the opportunities in the market, to produce more with less cost, to do all this in a more lean way; you shouldn’t do Agile, you should be Agile! Being Agile means: It reaches the reality by understanding the concept of “Business Agility” in its entire cycle which extends from the emergence of a demand for an opportunity to be caught or a problem to be solved, the carrying of code for each part produced. A successful Agile methodology is not only supported by a cultural transformation but also makes it possible to achieve real agility by changing the state from being on flow to doing. By looking at the history of agile approaches, we see that it is far beyond IT and today many companies use end-to-end integrated solutions to improve their innovation processes.

Agile is not just doing a job in a fast way! Another false perception in the organizations is that agile is a concept based on urgent business. Concepts like agility, lean are not values that can only be measured with speed. While the documentation has become simpler, the planning is done more frequently and in more short-term sprints increases the speed, it is necessary not to stop producing high-quality work. Otherwise, the methodology creates a cycle that only creates temporary and limited solutions to the needs. This false perception may cause you to miss the big picture or doing a tampon to problems with temporary solutions. In addition to expressing much more than that, Agile evolves with the development of the ability to produce quickly by adapting agility to the right jobs of teams who are running together for the same goal.

Agile is not an approach that doesn’t apply to business analysis activities! Maybe this point is a part that can be interpreted falsely in this methodology. Quarterly, 6 months, yearly plans don’t work as much In the software development life cycle anymore; these are already old discourses in which the designs and scopes were changed rapidly during the project. That doesn’t mean giving up on business analysis activities. Preparation of PBIs (Product Backlog Items) and prioritization that comes from the business units in organizations are necessary for the companies to produce the job in minimum time to reach their vision. Distinguishing the projects in the “Epic-Feature-PBI (User Story)” format, the agreements to be achieved on acceptance criteria, the designs that are made, elaboration of each user story to be completed on the whole system will continue to be the most fundamental business analysis activities. In case of moving away from these structures; accessing product/process details just through the working code snippet means the disappearance of corporate memory and would bring many supervisory problems. 

In the Agile approach, “breaking down” the tasks doesn’t mean breaking down into small pieces! Most of us understand that in every resource we read and in every application we examine, the biggest change in the agile approach is to give up on large, detailed, and complex scopes and switch into a piece by piece production in a very short time instead of long-term development processes.

The most critical point that should not be mistaken here is to continue to project with small waterfall SDLC loops in sprints. It is an inevitable reality that every item included in the sprint will provide a positive value at the point of completion for the customers/users. The biggest responsibility belongs to the Product Owner. He/she has to support every PBI/MVP concept that will be included in the sprint. So, PBIs should function in line with the company strategies for products/services that customers envision in their minds, and should contain the minimum parts that carry the most basic features. When it comes to minimizing the work here, the real agility is not only to complete a part of it at a certain time but to break into meaningful small parts in the sprint. Then, it will take the organization one step further in producing the right job. Although this fragmentation is difficult in software projects with high regulation and cost, which are complex and dependent on many stakeholders, it is not a waste of time to spend the necessary effort for this activity in a real agile formation.

In the agile approach, it is not possible to carry out activities from an individual perspective! Considering the history of Agile, all of the methods in this framework such as scrum, kanban, lean contain teamwork within themselves. For example, if we take Scrum as an example, the point of view is to approach the sprint in a holistic manner at the daily meetings, as well as the necessity to plan the day most beneficially as a team and to move on to the flow. So the teamwork concept is protected. Within the framework of the commitment given in sprint planning; the outputs obtained at the end of the sprint such as “velocity” and “innovation rate” are evaluated by the whole team. “Retrospective” processes shouldn’t turn into individual arguments, the success of the sprint should be evaluated by the team. In Agile being, all the activities always depend on teamwork. Teams made up of competent people who can run together to the goal will be those who can take agility to much higher levels.

If we can internalize what we see when we look deeply from all this “… what is not” window, perhaps we can better understand AGILE, the fact that it produces this lean, simpler, more valuable work in a short time.

If we perceive it as just distributing the roles suggested by the methodology, performing the activities without qualification, and describing breaking the work with a single sentence; in addition to agility, there will be insights which reflect the decrease in production quality, inefficient processes, low-motivated employees and unhappy customers. 

To qualify the transformation of the software world, to increase the creation speed under the roof of lean approach and simplicity, to create value; the philosophy of Agile should be understood and the organizations should have teams that have a compatible culture with their organizations and they should keep learning all the time. Companies should not leave themselves to the Agile wind, on the contrary, they should live in the reality of their progress by taking the wind right behind them (being Agile)