Software Development - A Few Lessons Learned

Over the years, I’ve been fortunate enough to witness teams succeed, and fail, in the software development life cycle. When the team fails, occasionally it is due to the outcome being out of their control - perhaps it is because of shoddy integrations, or in some cases, just bad planning and not understanding the full delivery pipeline. One of the biggest reasons is a misalignment with the expectations of the client. In some cases, the solution is either Greenfields (new) or it inherits an existing code base that you must tackle head on.

In this article, I will discuss a few key points which have helped me in the past to deliver projects successfully.

Client

Stay close to your client and form a partnership - understand their business, intent, and needs. Don't be shy to ask difficult questions to engage with your client and understand why they are asking for a specific requirement. We are all just human, trying to make a success of the project/product and engagement.

CI/CD

CI/CD has always been an important factor, and I want to reiterate its importance by ensuring that the CI/CD is set up for all of your clients - new, existing, and old (legacy). Without this, it delays the delivery to QA/UAT and Prod, and ultimately forces the team to focus on deployments and infrastructure, rather than focusing on refinement, quality, and features. Preparing this in Sprint 0, will ensure that you don't have to worry about it later.

Versioning

When working on enterprise-wide software, versioning becomes a key player if you have multiple modules/services with different versions. Backwards compatibility and an understanding of what is different in each version, is of major importance. When you upgrade to a new version, the CI, along with unit tests, will quickly identify any areas where the services could potentially fail due to upgrades and misalignment on mappings, endpoints, etc.

QA / UAT Environment

Having a QA / UAT environment is beneficial to test the respective system and to debug issues, should there be any. Not having the correct environment to debug, can result in a nightmare of poking around in the dark.

As a result of the world we live in today, along with the massive amounts of progress that's been made in virtualization and container-ism, it is relatively easy to replicate environments.

Managing Multiple Teams in Cross-Border Locations

Having  numerous teams in cross-border locations, whilst working together on the development of features and delivering support, is not an easy feat at all. This is especially so when you are trying to ensure that the team buys into the same vision and that their priorities doesn't collide, but rather align. Due to the distance between the teams, there is a communication gap by default. These issues can be addressed using video call stand-ups and conference facilities, which help with face-to-face communication.

Keeping the roles well-defined and understood within the teams is just as important to ensure that everyone knows what their responsibilities are, and that they don't clash.

Seniority and Balancing the Skills in the Squad

Having a balanced team of skills and different levels of experience is vital for the following reasons:

Running a project without an experienced leader, whom has not yet had any failures to learn from, is like taking on a project and learning on the go, at the expense of your client.

Ensuring the team has opportunities for growing as individuals, is just as important. The need for graduates and experienced engineers balances out well, as the experienced engineers will mentor/coach and guide the juniors, providing them with the necessary support.

Remove Change Management and Safety Roadblocks

It's easy to fall into the habit of building roadblocks, sign-offs, and approval checks to ensure that the quality is spot on. In the old ways of working, this was the way to go, as you would build a product over a period of 12-18 months, with security gates throughout the delivery of the project. In today's world, we are pushed for delivery - with the aim to deliver code to production ten times per day. Back in 2009, Flickr had the goal of 10 deploys per day. Yes, this is almost 10 years ago.

When it comes to quality, having various approval levels and dependency on multiple departments for quality gates, slows down the delivery and ultimately doesn't empower the team, as others need to validate that the work provided is "correct."

I'm not saying quality checks are wrong, all I’m saying is; empower the team to run with the quality gates so that they can own them and improve on the process.

Culture is King

Having a culture which supports innovation, ownership, and building relationships with your fellow teammates, is non-negotiable. A culture of shared ownership and responsibility between teams and team members, is important. When people become selfish, and they don't see the need to build a relationship with his/her fellow teammate, you will quickly see unhealthy competition with selfish intentions. Generally, a culture like this is not just in your teams, but a company-wide issue, which raises the importance of getting it right.

Make it Visible

Your fellow teammates, management, and other teams need to be able to see the progress made within the team. The blockers and dependencies must be shown so that they can be tackled and resolved. Making the work visible enables everyone to see the holistic picture of the direction the project is moving towards. It's an easy obstacle to overcome.

Manage the Work in Progress (WIP)

Let's not create false perceptions for ourselves - simply said, doing ten things at once never works. We can hardly read a text message and listen to a comment in a meeting, so why do we even try...?

With the correct prioritization, one can focus on the most important task at hand and complete it before moving on. If you are in a managerial position, delegation and trusting others to own the respective assigned task is just as important.

Make sure the WIP is small enough and achievable. If the tasks grow into weeks of work, break it into smaller chunks, so that more than one person can get involved, ensuring faster progress. Don't underestimate the power in the satisfaction of completing a task and moving on to the next one. This builds confidence and keeps the momentum going forward.

Summary

A software development team should be a collection of mixed skills and experience with opportunities to grow and learn. They should function without much influence or guidance from someone outside of the team. They are stable, cohesive and has an emphasis on collaboration. The roles are clearly defined, the vision is understood, the work is made visible for all to see and they have fun.