For many years, we have been learning by doing. We have delivered hundreds of projects, for tens of customers, and we are still doing it. By doing that, we have gathered a great expertise in many different technical practices that we consider as falling under the umbrella of Technical Excellence.

Principle number 9 of the Manifesto for Agile Software Development states the following.

 Continuous attention to technical excellence and good design enhances agility.

This article describes what we call Technical Excellence at Agile Partner

The four pillars of Technical Excellence

At Agile Partner, we divide Technical Excellence into four pillars

• Agile development practices
• Evolutive architecture
• DevSecOps
• Cloud

We believe, and we have learned from experience, that each of these four pillars really enables Technical Excellence and that in fact, they reinforce one another. Only by combining all the practices covered by the four pillars, will you experience the benefits you could expect.

Agile development practices

This pillar mainly covers  technical practices that are often associated with eXtrem Programming, the Software Craftsmanship movement, and agile testing.

This pillar includes technical practices :

• Collective ownership of the code
• Coding standards
• Simple Design
• SOLID object-oriented programming patterns
• Clean Code
• Pair/mob programming
• Test Driven Development
• Behavior Driven Development
• Continuous integration
• Technical debt management
• Continuous Learning
• Technical leadership

Commonly regarded as good practices, they are unfortunately often ignored or overlooked by software development teams, who usually claim to be “too busy” to care about them. The problem we face here is that, without adopting good practices, the team will take more risks and ultimately  get slower and slower.

Even if adopting these practices required a bit of time at first, once implemented these practices will reinforce one another and start saving a lot of time and tremendously reduced risks. Instead of starting from scratch, which can seem a bit daunting, we recommend to ask experienced people for help, which will accelerate the adoption of such practices.

Evolutive architecture

This pillar covers principles and practices that allow your software architecture to be flexible in order to evolve in time and take change into account. It’s not a question of “if” change will occur in your software product, it’s a question of “when”.

Change may occur in different aspects of your software product:

• Scope and requirements
• Scale and performance
• Legal and regulatory

This is especially true if your product becomes popular or if it has a long lifespan. Our industry needs to acknowledge that we cannot predict the future, and that since we cannot control change, we need to embrace it. We need to be able to take architectural decisions that will respond to our current understanding of what we need, without closing any door for the future. The team should be able to take structural decisions just-in-time, without mortgaging the whole project.

Generally speaking, loosely coupled architecture is a safe bet. But in some cases, a plain old monolithically application might just do the trick.

In order to raise the bar, a team should know about:

• Clean Architecture
• Distributed systems
• Domain-Driven Design
• Event-driven/reactive apps
• Microservices
• Containers and functions
• Designing APIs
• Serverless
• Designing for scale

You generally know more about your product in the middle or at the end of its development cycle than you knew in the beginning. But you should not try to overdesign for every possible use case upfront. Your software design should therefore be able evolve in time. It should be simple and efficient in the beginning to allow fast release cycles. And, it may become more advanced along the way, to cope with new features or larger scale, without compromising delivery speed or becoming too complex.

DevOps

DevOps aims at bringing developers and IT operations closer together and share responsibility for the quality, availability and resilience of the system. More than a process, DevOps is a cultural change.

Filling the gap between Dev and Ops is not easy and requires some change in the organization. Embracing a DevOps culture comes with its lot of technical and non-technical challenges.

This includes :

• Promoting a DevOps mindset
• Leveraging a version control system
• Defining the appropriate branching strategy
• Implementing CI/CD pipelines
• Using Infrastructure as Code
• Shifting left on security
• Empowering teams and delegating responsibility
• Fostering a continuous improvement culture
• Implementing observability and monitoring
• Adding SRE to your teams

Some people think that DevOps is mainly about automating everything. But it’s actually more subtle than that. Yes, there should ultimately be big improvements if you manage to automate most steps in your software development and release process. It will reduce risks, eliminate waste and therefore reduce the lead time for new feature delivery to the business.

However, to get there, you will need to apply the same old agile principles that work so well for a dev team to IT operations. That means include Ops as early as possible in the development process, which leads to better communication between the two and ultimately better organizational performance.

Cloud

According to the State of DevOps 2020 report:

Using private clouds, public clouds, hybrid clouds, or a mixture of clouds, corresponds with higher organizational performance than the use of on-premises servers alone. Those who use multiple public clouds are 1.4x more likely to have above average organizational performance than those who don’t.

Transitioning to the cloud is no small achievement. It requires a good understanding of what cloud computing is and the different responsibility and deployments models that exit. It requires defining a landing zone, establishing a migration strategy and monitoring cloud adoption and change within the organization. Companies who move to the cloud need to acquire new skills or reinforce existing ones, therefore roles and responsibilities will have to evolve.

Companies who develop natively on and for the cloud also have their own challenges. They need to learn new cloud design patterns, learn about the different options the cloud providers offer, pick the right services, and monitor their workloads.

Both need to develop skills related to:

• Designing applications for the cloud
• Governance
• Operations
• Security
• Compliance

Cloud adoption or transition requires a good DevOps culture, a flexible software architecture that can evolve, and excellent technical skills. It often also leads to the emergence of new roles, like the role of FinOps, who becomes essential to operate the shift from a CapEx mindset to a more OpEx mindset, where costs are monitored and improvements are made regularly to decrease the costs while maintaining an equivalent level of service.

The strength of Agile Partner

How did Agile Partner come up with the four pillars of Technical Excellence?
The short answer to that question is: experience. With time, Agile Partner has developed some knowledge and skills on all 4 pillars.

We have learned during the first years of Agile Partner how to develop software in an agile way and how to leverage agile development practices to ensure quality and speed.

We have discovered that, in order to be truly agile, we need to design an architecture for our product that supports changing requirements and evolves to scale and stand the test of time.

We were early adopters of the DevOps philosophy. Applying the same agile principles that we already knew to operations was a logical next step. It was only natural for us to start looking into the new emerging practices and tools that came with it, and therefore we gained some expertise on the subject.

With the emergence of cloud computing, we discovered a brand new playground. We started developing systems for our customer that were natively designed using services from the public cloud. Through certifications, we became partner for both Azure and AWS. Along the way, we worked with other customers on their cloud adoption journey, whether on public, private or hybrid cloud.

It is because we have learned how to do it well, that we can now help others do it.

We are technology experts. We are coaches. Thanks to this double competence, we can address a large scope of topics and issues when it comes to the four pillars of Technical Excellence. From coaching C-levels to help them bring change into their organization, to helping Devs and Ops figure out how to improve the quality and speed of their product releases. We are here to help!