The road you should not follow

I guess this lesson had to come with time. When work turns to routine, we tend to loose focus and stray away from the place we’ve started. Sometimes, conveniently ignoring what made us passionate just a while ago.

I’m getting ahead of myself, let me start from the beginning.

Our scrum teams are mixed. They compose of frontend developers (FE), backend developers (BE), automation developers (AT) and QA engineers. There are no fullstack developers that can do it all. Developers rarely perform QA work and FE developers usually are not familiar with BE programming languages (and vice versa). Sometimes backend can assist with automaton, but this is usually the only way those disciplines ever mix up.

Because of that, our sprint planning, quarterly planning and even long term planning is usually split accordingly. We can’t count on frontend story points to be performed by a backend developer for example. Everything is divided.

We started out with mutual stories. Stories that contained a business requirement, that included all four types of roles. BE would code the infrastructure, FE would connect the UI to the services, QA will test it all and AT will automate the manual test QA performed.

The first thing to split out of these stories was the automation. Being the last in line of development put very big pressure on AT to finish the story in time. When it didn’t finish, all parties were disappointed that a big development didn’t make it to demo. It obviously wasn’t the AT’s fault, but being last in line, and the only one who didn’t close the story, played it’s part.

So we split the stories. We wrote AT stories separately so we can close the development story and achieve more points at the end of the sprint. AT would present the test on the following demo with no pressure being put to complete it quickly.

Next thing to go out was QA. Not all of the QA, we still had small testing during development, but the major end-to-end test that combines all pieces together was separate. That meant that the development could be done a sprint before, but major issues would be found a sprint later, when developers are already working on a new feature. But this too, gave us the option to close the stories. Developers felt good about themselves, they felt competent to complete their sprint commitments and present it in demo.

FE and BE separation was not late to follow. A long sick leave of FE developers, and the long practiced “method” turned up to be a solution again. Why give BE a bad feeling that no story was closed in the demo? Let’s split the stories. Have BE create the services, and FE can connect to it once we have someone available to do it.

Language changed pretty quickly as well. It wasn’t ‘we couldn’t complete a story’, it was ‘they couldn’t’. Instead of taking care of our bug, it was their bug. If an AT story was at risk, no BE developer help out, it was easier to move to the next BE task in line. Comfortably forgetting that the other part of the split story will not finish.

We became teams of individuals, so far from what I believe in, what I practiced just a while ago. So far from what I envisioned us to be. No common ground, no common goal, waterfalling our way through the sprints.

Luckily, someone did pay attention. We strayed aside, but didn’t get too far to that pit-hole. There’s still time for a sharp turn, so we can get back to building a team that actually works together.

We will start with mending all the different stories. Gradually. One discipline at a time. Parallel to training our team members to backup each other. Even if only in small tasks. Even if it is not their primary discipline. Our aim is to work on stories together, and have a common feeling of responsibility over bugs, and a common feeling of pride over a well developed feature.

We have a long road ahead of us, except now we know where we’re heading. Hopefully never to loose way again.

I consider myself a person who likes to learn everything by experience. I was never one of the lucky ones who could learn from other people’s mistakes. But hey, maybe you can learn from mine.