Giving developers a seat on the table

The digital economy has propelled a new perspective towards software development and deployment.

Jeff Bezos, Ex-CEO of Amazon, once said that his business wasn’t the content of their deliveries, but the software that made it possible to send those boxes to their customers. 

The final outcome is not necessarily the main occupation of the company, for without a platform, or software that would allow all transactions to take place, there wouldn’t be a tangible product. 

Companies like Uber, Lyft, or Spotify are focused on creating impact. Among many of the reasons that set them apart from other not-so-successful companies, there is one that stands out: quality software. 

Now more than ever, creating impact resides in originality. The moment is now to provide developers with the room to be creative rather than just coders. 

Quality software is not built in one day. A lot of companies embark in the adventure of adopting agile methodologies thinking this would solve all their problems. Not long after that, they realize nothing has changed. A profound change in the mindset of the company is needed. 

Listen to the ones with the ‘know-how’ 

Developers should be able to express opinions and make decisions about the technology they are developing. All in all, they are the ones with the deepest and more detailed knowledge on the subject. 

Juan Pablo Delprato, Developer and Team Leader on Moove It, thinks that one of the most frustrating issues for developers is that generally “they are not the ones who define WHAT needs to be done, but only HOW is supposed to happen”.

He argues that being the ones with more expertise in the HOW, they are able to observe things that other team members in roles more related to management don’t see. “When you are the one seeing those things first hand, you generate questions or ideas about the WHAT more than the HOW, even more so than people who are strictly related with the WHAT (PM, PO, clients, stakeholders). Many times that ideas are of great value to the product”.

If developers were to be introduced to the discussion early on, problems that may occur or objectives that don’t align with realistic possibilities, could be seen before the planning stage. 

Assign problems, not tasks. 

Developers can be described as being many things, one of them is problem-fixers. But assigning a task without giving context, reasons why it should be done, or contemplating other possibilities to solve it might result in bad quality software. 

Humans find motivation and passion on activities that involve problem solving. That gives purpose and demonstrates the confidence we have in other people’s creativity. 

Juan Pablo illustrates this problem with a clever metaphor: “If someone says: we have to lift this rock, how can we do it?, is not nearly as motivational as someone saying ‘This rock is on the way to discover the cure for cancer. We need to lift it to save millions. How can we do it?”

An interesting thing here is that you would still be asking HOW while giving purpose, reason and context, three crucial aspects to achieve any goal. 

Keep developers close to customers 

A big problem that many developers have experienced, is being in the dark regarding the customer. They’d receive a task, finish it, handle it and the Team Leader or the one in contact with the client, would be the one explaining it and probably taking credit for it. In Moove It, things are done differently. 

Gabriel Fagundez, COO, explains that “our developers are always in contact with the client. They speak their minds in meetings with clients, and are always encouraged to share their expertise to upgrade the product”. Whether it has to do with core decisions, design processes, possible new features, or even discussing the size of a call to action button, the dev team is present.  

Developers working in Moove It are involved in the decision process from the beginning. They are the ones being consulted to know if a feature or solution can be achieved and how to do so. As experts on the subject matter, they are frequently challenged to find different ways to solve a problem, along with the PM, PO and other members of the team. Moreover, many of our current Team Leaders are in fact developers who previously worked as part of other projects and teams, and now are leading their own. 

The teams have daily meetings and weekly sprints to make sure that the project is always on the right track, the members of the team know why they are doing what they’re doing, and the user stories and personas are eventually being questioned and improved. 

Tolerate failure and keep up your continuous delivery pipeline

Companies might benefit greatly from applying a culture of experimentation. Procuring an environment where failure is not punished, but conceived as a learning opportunity. This could mean giving developers the possibility to experiment and to fail in order to succeed. These techniques along with some of the ones previously mentioned, are key to maintaining your continuous delivery pipeline and actually discovering if your software is working or not and why, ahead of schedule. 

It’s mostly about delivering, creating robust MVP’s so that real waste is minimized. 

Although there are no magic recipes, maintaining an open line of communication and encouraging all parties to speak their minds and collaborate towards projects’ success with weekly or daily iterations will always result in good outcomes.