Software Development Case Studies

The Challenge

I started leading a development team formed initially by three developers. At that moment, I was doing all the Code Review, functional testing, and releases, which was fine, as we were a small team.

However, as new members incorporated to the team, I started to feel overwhelmed. Soon, I found myself reviewing dozens of Merge Requests every day and working extra hours to achieve milestones. As you may imagine, that's not scalable.

The challenge was finding a way to manage a growing development team while keeping milestones.

---

My Approach

The first thing I did was divide the whole team into smaller ones (~4-6 people per team). Then, we embraced Agile principles to manage our milestones and hired QA roles.

Once the teams were formed, I provided goals (what needs to be done) to the teams and let them figure out the way to achieve them (how to do them). To guarantee collaboration among different roles (QA, Developers, Design, DevOps), we included each one of them in specific teams so that they could be part of the development process since the beginning.

I also gave the teams trust and autonomy, so they could feel free to organize themselves and innovate. That way, each team became the owner of their code review, testing, and releases. We also created a shared knowledge repository and summits, in which every team would share its own experience and expertise.

As teams were innovating, it was inevitable to make mistakes along the way. However, each failure was also learning. Instead of just preventing failure, I helped the teams implementing systems to fast failure recovery, so when they failed, they could recover, learn and improve quickly. So, whenever there was a failure, instead of asking "Whose fault was this?", we asked "What happened? What can we learn from this? What can change to avoid this in the future?".

However, failure has to be non-lethal, as nobody wants the whole system to break down. To achieve this, we decoupled the software in little pieces and delivered software changes to just a few customers, so failures would only affect a tiny portion of the system and users for a short period - as teams know how to recover fast. Once new features passed the production testing, we delivered them to all customers.

---

The Results

Overall, we discovered that focusing on developing people, and not just products, gives the best results. Specifically:

• We created a flexible workflow based on Agile that was continuously improved by the whole team.
• We increased productivity and reduced number of bugs, which most of the times only affected a few customers.
• Developers were happier coding the way they wanted to, which also gave them a sense of ownership.

The Challenge

The development teams were already working with a pseudo-Scrum methodology and sprints every two weeks. However, they weren't entirely following Agile principles. To be honest, the organization was quite chaotic.

One of the main issues they had, is that managers and the rest of the company didn't have a clear view of what was being done nor what was going to be released. When a task was re-scheduled, nobody could tell what impact it had on the roadmap, which caused confusion among the company and even the customers.

Also, we were devoting too many resources to not priority products and the other way round.

To sum up, we needed a clear way to define a road map that would adapt to changes, make it visible to the rest of the company and have clear where we were putting our efforts. That's why we decided to embrace Agile.

---

My Approach

Alongside with all the development team members, we read about Agile development. Then we gathered all together to solve common doubts and adapt our workflow to Agile. Once the workflow was clear, all teams started following it.

Some days later, we did a follow up to see how they were going with Agile. Surprisingly, production had felt down. The main issue was that most of the teams were strictly following the Agile methodology. Specifically, they were devoting a lot of time to:

• write very detailed User Stories
• lots of feature estimating sessions
• long daily stand up meetings

Obviously, they suddenly had less time to code.

To solve this issues, I remind them that Agile should be seen as a set of principles, instead of a methodology set in stone; or a set of tools, instead of a set of rules. By looking it that way, we decided that teams were free to:

• avoid writing extremely elaborated User Stories, or skip writing stories at all if it took more time than coding
• schedule just 1-2 estimating sessions per week, or even skip those sessions if they weren't suitable (especially for teams that were developing a prototype)
• minimize stand up meetings in time and periodicity, or even do them online via Slack

The global idea was devoting as much time as possible to code, using Agile principles in a way they would adapt to each team needs.

---

The Results

After solving the initial issues and giving the teams some time to adapt:

• We obtained a flexible and understandable road map, which we could share with the whole company.
• All managers and C-levels knew how many resources were devoted to each product at all time.
• The development teams embraced Agile principles and became fond of them.