Scrum, low-hanging fruits and delivering value

It feels amazing as a developer creating value by picking all the low hanging fruits and giving them to people. Nothing better when you see all the places your skills can help people around you. Trust is build up around you and people believe you will deliver when they ask you for help. The whole thing are build upon mutual trust, they say what they need and you promise you will do it.

But things begin to fall apart when miscommunication starts to happen. What needs to be delivered are not clearly communicated and neither parties write down what is agreed upon, because why should it be written down? It works so great and very little time is spent on programming aka. the supposed value. It also happens that not all tasks are low hanging fruits, some of the fruit has to be worked for, and how much work that is, is not communicated back to the person that needs the value. Why does the person asking for help have to know how long time it takes? Every time the person asked before it was delivered in no time.

This problem is what the Scrum framework tries to tackle. The idea of having a prioritized backlog of the most important user stories, what is the most valuable problems we can deliver. The scrum framework introduces this thing of a sprint that lasts for a certain period of typically two weeks. The idea is the team takes two weeks of "tickets" to work on into the sprint and that is what is agreed upon working on. To know how much work can be done tickets are estimated. Tickets are estimated with points to know how big a ticket is to solve. There is Sprint planning, Sprint Retrospective, Mid-sprint meeting. Looking at it from a bird's view it is very different from the start, with a lot of processes.

If you look at this and think by using this process you are safe and have everything in system, it is a lie and the reason is: The goal is not solving tickets but delivering value to the user. The user don't care how many tickets that was solved, the care about what problem was solved for them. Here is the misunderstanding I see developers using the scrum framework, they get distracted by the big focus on tickets that they lost the overview of the value of their work and missed the point of the Scrum framework in the first place and what it tried to implement.

The other method of agile and scrum is waterfall. Here all planning is done first and the execution is done afterward and testing in the end. The problem is since planning often is so expensive and time-consuming that more specs are added to ensure that the most value is delivered during execution that while the whole project is done the world has changed around it. The problem is that while the product was developed no feedback was given from the real users of it and therefore no changes or corrections can be done underway. That is what Scrum and Agile tries to help with.

It is important that value is delivered in a sprint, and by value, it is something the user can use and not value in how many tickets were solved and how many story points that was. The team has to look at a user story and think about how they can deliver that in two weeks and the reason is user feedback is crucial. The likely change that the feature delivered was correct the first time is very small and while the user waited for the feature they either found a temporary (better?) solution or got closer to what they really needed.

It seems trivial that value has to be delivered in the sprint, like of course? But here the non-trivial come in, not all user stories given are low hanging fruits. Low hanging fruits can be solved easily in one sprint. This is where the true strength of the team comes together and helps each other. Their goal is to deliver value together and work together. That means looking at the user's need and figure out together what can be done and help each other do that. If a task is big and both frontend and backend have to change, the team should come together and ensure that the value of both parts comes together before sprint end. The frontend and backend in itself does not solve the users problem even though both have tickets attached and storypoints.

The user story should not cover multiple sprints because that means that value was not delivered in the period that was agreed upon. The team should look at a user story and think about if they can deliver that in two weeks and if they can't they have to come back and say it can not be done the scope has to change. They should not break apart the user story by nipping it from the corner breaking it apart slowly, breaking it into tickets, and solving those slowly. If that is done no value is delivered to the user because work is being done but it is done in a waterfall way where no feedback is coming from the user as it does not solve their problem. A user story is brought along multiple sprints and from the outside, it looks like no progress is happening. The worse thing that can happen is that each member in the team begins to focus on the low-hanging fruits to either/or show progress to the outside and to highlight themselves. This is not only detrimental to the team's ability to deliver on bigger things but erodes trust unknowingly by each other team member working for themselves. So much of delivering a feature is not the actual work on the feature but understanding, communicating, testing, leading, documenting, and reviewing. Each team member in a sprint team is also a leader. A leader focusing on delivering the feature that the team agreed upon delivering to the user and ensuring all ends come together in the end, not detaching themselves from the userstory and only focusing on delivering the tickets assigned to them on the sprint board.

That is how the team can be a success and do amazing things.