Nice post regarding scrum / kanban / devops practices, but since the accent (and the title)
was on "Agile", I felt the need to respond to some of the common misconceptions about Agile that I found in the post.
"We are doing agile right"
> There is no right way to do Agile, nor can you, "do" Agile.
Agile implies "Flexibility and Adaptiveness" (you can only "be" Agile)
"Softray Solutions utilizes agile methodology. Agile is a process by which a team can manage a project by breaking it up into several stages and includes constant collaboration between stakeholders and Softray teams. The two methods Kanban and Scrum are the most frequently used, depending on project characteristics."
> Agile IS NOT a process and defines no processes.
Agile is a set of values and actually the very first Agile value is:
"Individuals and interactions over processes and tools"
It is important to say that Agile is not against processes but instead values individuals and interactions more.
(processes and tools are a result of people interacting with each other)
Scrum and Kanban are two of infinite number of ways of implementing Agile practices,
but adhering to those frameworks alone does not mean you are Agile - they are only a set of guidelines and have to be adapted.
There is no process in the world that can work for every team / organization.
"No matter the method, due to the agile methodology used, the project scope is divided into epics. Epics represent a module in the system. Epics are further divided into features. Features are broken down into user stories. The three definition levels offer the possibility to track project progress on three different levels based on preference and need."
> Not true.
Agile says nothing about how projects should be partitioned (and it definitely doesn't mention "Epics")
Agile only values working software over extensive documentation and responding to change over following a plan.
Some Agile implementations do partition work in iterations and small releases which is a very good practice (but Agile itself does not imply this)
"Epics and Features are usually defined with the project scope, however, if the need arises new ones can be added, removed, or changed. User stories however are a lot more adaptive and subject to change up the point when it is either selected for development in Kanban or in sprints. Sometimes it is also possible to adapt it during that period too, however it is not advisable as precious time can be lost. As an alternative, development can be suspended, the story removed from the sprint/work and another one selected instead."
> Like we already said, Agile ipmlies flexibility and responding to change and there should be
little or no constraints regarding this. Also, there is no one way of handling this. (it's a core value)
"During the planning meeting, stories are selected for development and a developer from the team is assigned. Firstly, the description and acceptance criteria are clarified to all participants in order to make sure all team members understand the big picture."
> If you are being Agile (even per scrum), storeis "are not selected" nor are developers "assigned to them".
Agile (and scrum even) imply self-organazing highly functional teams whose members are not "assigned" work, but rather, they "take" work.
Also, all team members should understand the big picture a long time before this moment.(and should even be involved in creating the stories)
"Once confirmed, the developers are playing “story points” poker. The story point is loosely connected to a day and signifies how long, and complex will it be to implement the story. The story points are assigned as Fibonacci numbers: 1,2,3,5,8,13. It seldom happens that a story value is 8 or 13 points. If the poker play indicates that amount of complexity, the project manager will work with the developers and break down the story if possible. That is being done for two reasons: the first one is to avoid complexity and get simplified tasks, the second one makes sure a story can fit into a sprint. If it turns out that it cannot be broken down, that story gets higher priority to minimize the risks and impact of that task. The estimate is compared to the original estimate and discussed to identify the difference between the initial understanding and the current one. After the meeting, each of the developers breaks down the story into individual tasks with a time estimate which is then added up to a story estimate."
> This is makes little sense
"For Kanban, the meetings are not part of the process. Instead, the developer receives the next task as soon as they finish the previous one."
> Again, devs should not "receive" tasks (Customer collaboration)
Agile also tends to strive towards a flat hierarchy and has little need for explicit project manager roles, so
mentioning Agile in classic corporate project management context does it little justice.
Again, as a disclaimer there is nothing wrong with the post, you seem to be employing healthy practices,
and it's an ok sumarry of scrum / kanban practices, but the Agile aspect of the post was not really on point.