Category: Agile

Scrum: Survival guide for devs

Scrum: Survival guide for devs

Working as a dev in Scrum can be really hard, let’s face it. With constant deliveries and no time for tech improvements, it is easy to feel like in crazy race to nowhere. These are the facts that I found myself most annoying, and how I try to deal with them.

#1 Management not involved

Very hard one. If management is not involved, you will not be doing really Scrum. And sell Scrum to management is impossible it you do not support it with metrics or very un-questionable success stories. I have read stories about changing processes without stating that you are going on an Agile direction, and when the changes are made, reveal the intention behind. I think is not the normal thing: if mangament does not want to hear about Agile, probably is beacuse it is the type of management that does not allow teams to change their processes easily. But if you feel you can makes changes, but your company is just against Scrum/agile thingie, maybe it makes sense to try this approach.

 #2 Pressure -all the time

Delivering tested features in 15-days cycles is exhausting, and if there are hard deadlines, dealing with management while delivering can put devs under a lot of pressure. You have to estimate carefully to avoid throwing yourself to the lions, and to get used to renegotiate the scope of the stories with the PO. If you came across some undefined behavior, do your best to create a follow-up story for that use case and concentrate on the originally defined scope. If you end with some extra hours at the end of the sprint, you can pick another story (or read a blog post, maybe ^^). QAs are your friends. Involve them in the discussions with the PO, to keep them aware of all the story details and avoid any misunderstandings that can delay the acceptance phase.

#3 Micrometrics & violent transparency

You will be analyzed at the end of each sprint (or even more often) and compared to your teammates and to the rest of Scrum teams. It is ok. Burndowns are more visual than the percentages we gave in the old times, but it is the same. Just try to raise your problems/blockers early (in the daily or even before if it is critical). If you think that you are regularly performing poorly, talk with the Scrum Master. He or she probably has clearer view of the big picture and can give you some useful insights.

#4 The long-term goal is missing

With the backlog changing all the time and the pressure to always keep your eyes on the next tiny story to deliver, it can be hard to see the big picture or the long term goals of the project. Get involved in the plannings and retrospectives and ask the PO to provide and update a roadmap. When possible, do attend the demos that include stakeholders or final users, or at least try to get feedback from the assistants.

#5 No career plan / no expertise recognition

Scrum does not have roles. Everyone in a Scrum Team is just that: a Scrum Team member. In addition to this, you have to give reports each day, which, apart from killing creativity, feels a little bit like being constantly observed. And this usually happens only in the early stages of a developer career, although usually you never put a team of juniors to work in Scrum. This “junior feeling” usually depends on how the Scrum Master filters the pressure and how much ownership of the increment implementation he gives to the team. Try to win the leadership of the areas that you master: take the opportunities of giving guidance to the rest of the team in those areas to become a reference.

#6 – Technical debt

It is really frustrating to see technical debt grow as the sprints pass, and this can be a hard one to fight for if management or PO really do not understand/care about the impact of poor code quality. If the team and the PO can reach an agreement of a discrete amount of story points that are destined each sprint to code improvements, that would be great. These story points can be assigned to each developer, leaving into his hands the refactoring of the code that he is delivering, or you can assign the whole amount to an experience dev and let him refactor and re-test complex component or implement some transversal improvements. Also, it is very important to maintain a good level of Unit testing coverage and to add a static code analysis as part of the integration build.



Waterfall is broken. I really like Scrum and I think some of the ideas of the Scrum Guide are very useful, but I think we can do better and with less hypocrisy.