Using Agile In Parts

NOTE: I am not an expert here.

I have never been a fan of Agile methodology. In my opinion, it is not at all a very efficient way to develop software. It introduces aspects and "ceremonies" that are not at all developer pleasing.

Below are the 3 main reasons why I "do not want to but have to", work in Agile teams.

1. As a developer, it constantly asks you for estimates. Estimations work well if we have good experience in working on similar things in the past. But for a developer, that just means boring work as they do not get to explore other stuff. On the other side, estimating work on unexplored territories is useless as 99% of the time the estimates are not correct.

2. Sprint review asks for a client demo every few weeks. In the initial stages of the project when we are still setting the infrastructure, the Black and Blue terminal screens do not make sense to the client. This is a frustration for the client. The agile method works well if we already have an established product, and the project is about enhancements and adding new features.

3. There is a high dependency on the effectiveness of Scrum masters. Scrum masters proudly mention that they are not technical - this is a problem. It should be noted that the majority of Scrum masters come from a tech background. Not sure if this is related to that, but at times they DO NOT have people and work management skills. It is very easy for developers to fool them and steal time.

As I said, these are just 3 reasons, I could write a book about why I do not agree with Agile.

However, ironically the reason for this post is that I have found some useful parts which I think all of us can use. But before that, let me mention how I track the progress of work.

I try to keep it very lean using Kanban. But Kanban can fall short when the team grows, and the interrelation of work packages (dependencies) is to be tracked. I am not saying they cannot be tracked, but it becomes difficult to package and release the work.

I sound like I am complaining a lot, but Kanban is by far the most relevant and natural choice I could make when tracking work progress. To overcome the above-mentioned shortcoming, I use the "Epics" concept in Agile. After all, there is nothing wrong with the Hybrid model.

Product -> Releases -> Epics -> Stories

That is a very generic hierarchy, and without wasting much time, I just stick to it. So whenever I think of a new feature, I create Releases. For a long time, Epics was not there in the above flow. So All the stories were directly tagged to releases.

But in the real world, each release may contain several components which are developed separately, but they still depend on each other. Roughly, each Epic corresponds to a Git repo. That means, all the work that is needed to be done in a particular Repo, goes as a story in that particular Epic.

Do you connect with this?