Sometimes things go wrong in agile software development

I was once set to develop a talent assessment tool as a side project for a company I was working on. Two other developers with more company time than I and deep expertise in a different set of technologies were also assigned to the task. The three of us along with the director of operations of the office set ourselves to build the product and we failed miserably. Here are the reasons why I believe we failed so badly.

This was supposed to be a refactor from scratch of a solution I came up with during the hiring process I went through to start working for this company. At that moment I was put to the task of building a simple solution for this talent assessment problem they were until then managing with a spreadsheet. I remember being told to use Angular because that was the technology I was going to be using afterwards for client projects if I got hired. So I built it covering the basic features using Angular, Angular Material, Firebase and got hired.

When we decided to work on the refactor, I was told that I was going to lead the development with freedom to choose the tech stack and no worries about a final delivery date. We were supposed to move steady and slow following the Scrum project management pattern as close as possible. Up to this point everything seemed ok. Together with the other devs we agreed to use JS front to back. The other guys were both Ruby experts with a lot of curiosity about the Node.js ecosystem and I was the JS guy trying to optimize time by using at least the same language I used before which would allow me to reuse some of the code I had written before.

First week. We broke down some of the basic features we should implement first and set up a couple of sprints using a board and GitHub issues. The first tasks were all related to get the data persistance layer ready. One of the Ruby devs was a very smart guy obsessed with minimalism. Those were qualities but in some way turned out to be weaknesses. His obsession with using only minimal dependencies slowed down the team a lot and that started to raise concerns with our director of operations, the one who was playing both the PO and the stakeholder roles in the project scrum setup.

So at this point I would point out two of the many reasons I think the project failure is due to. The first one is the double discourse of our manager who happened to not be so patient as he sought to be at the beginning. The second is the lack of empathy and team playing ability of one of our team members who happened to put his own way of thinking in front of the rest of the team and above all in front of the very problem we we're actually trying to solve.

From this point on the project started to fall apart. I wasn't really being seen as a leader and they changed the tech stack to Ruby on the backend, keeping JS on the front with not much freedom to choose libraries as initially assumed. I was pushing for React because I wanted to try it but we turned out using Angular because our director of operations wanted to keep our tech stack limited to what he thought was useful from a company strategy perspective.

I guess you already got the bigger picture. Lack of trust and confidence between team members. Lack of purpose, vision and leadership from the management side. A lot of confusion and lack of communication between team members. I really don't know at what extent I was to blame for the project failure. It started as a side project that was supposed to be fun and an opportunity to learn new technologies and exchange knowledge but it turned out to be a complete mess with no clear mission and a lot of excuses. A couple of months later I left the company and abandoned the project. I maybe should have pushed harder for staying lean and avoid over-complicating solutions at the beginning such as changing the front-end stack, but I didn't because I thought I could and it ended up as it did. Lesson learned.