Agile Technical Practices—If Only You Knew Them!

How can professionals enhance their expertise? Through embracing best practices.
In my workshop “Built-in quality” the participants are looking for better ways to develop software development. When we discover a weak spot, a certain step in the software development lifecycle (SDLC) where the quality is low and possibly faults are injected, we’ll “install” a feedback loop and strategize how to:

• Enhance the product so it can go to the next stage
• Refine the process, to mitigate future occurrences and
• Educate individuals so they know how to avoid it from here after.

Community-driven practices serve as a rich resource for those improvements—if only we knew them. In my book, The Waves of Agile-Value Delivery in Medium and Large Organizations I strive to demystify key practices by contextualizing them with the agile maturity of the organization and the step in the SDLC where they yield the most benefit. This results in a comprehensive overview, mentioning practices that you do not have to, but you could use to become a more proficient developer and help to boost the value delivery. If only you knew them!

I was thrilled when I stumbled upon the book by Pedro Moreira Santos, Marco Consolaro, and Alessandro Di Gioia. In their 2019 edition of Agile Technical Practices—Become Agile and Efficient by Mastering Software Design, they unveil what they deem as indispensable practices for professionals. They assert that the proliferation of technical practices in recent years has been exponential.

With vast experience in software development, all three authors are committed to mentoring and educating community members on fundamental software development practices. They know them and distill three main practices that help you to become an adept developer. The book targets both programmers and software coaches. Since I am an agile coach more than a developer, and do not know how to code, I initially felt I might not be the intended audience. However, given the alignment of their approach with mine, I decided to delve into it.

So, what does the book entail? The authors identify technical debt as a primary impediment to the progression of software development, as software development projects stagnate under their own weight (p91). They reference the Software Craftsmanship Manifesto, which clearly makes an argument for well-designed and well-written quality software, and the reduction of technical debt. In their pursuit of effective practices, they distinguish between technical design practices, such as refactoring, and technical feedback practices like pair programming and test-driven development (TDD).

Pair Programming

Pair programming, fundamentally, aims to expedite feedback loops in software development. It transcends mere working together with a colleague, but has some strict rules, roles, and principles. It therefore requires a high level of maturity from you and your peers (p113).

I like that the book does not only describe the roles, but also has an eye for implicit pitfalls. For example, when one of the pairs has authority or power, this might make the other uncomfortable and influence the feedback given. A true point, and although the authors do not zoom in on cultural differences, I believe they may influence the effectiveness of pairing as well (p144).

The book has extensive lists of resources for each technical practice described. You can skip them when reading the book for the first time, but they enable you to deep dive into the topic when you are starting to implement a practice.

Test-Driven Development

TDD is a practice that originated in the late 1990s. It endeavors to minimize debugging time and the fear of code alteration by leveraging tests as living documentation that is always up to date.

This is typically done by applying the Red-Green-Refactor cycle. It starts by writing a unit test. Naturally, this test fails initially, indicating red: 'the code it tests has yet to be crafted.' The next step is to craft the minimal code needed to make the test pass and turn green. Subsequently, we try to refactor the code. While keeping it green, we optimize it by making it more efficient, readable, or understandable.

Each section is closed with exercises (called Katas) to get hands-on experience with TDD. As a reader, I am warned not to move on and take time to master the Katas. However since I am an agile coach with no real programming skills, I ignored the warning. No doubt it will hurt me later in the book, but for now I am happy to read on.

Refactoring and Design

Refactoring entails modifying code design to enhance its quality. According to the authors, while 20% of the value of refactoring stems from design changes, 80% emanates from enhancing code readability and comprehensibility (p217). This is typically accomplished by renaming classes, methods, or variables, by extracting or moving them to other places in the code base, or by deleting them if they become obsolete (p211). This should be done without changing the behavior of the code. So all tests should stay green. Refactoring can also be done manually. But it is advised to invest some time in getting to know and customize your integrated development environment (IDE) so you can do automated refactors that are time-efficient and more controlled.

Figure 1 - Click to Enlarge

Throughout the book, the authors facilitate a deeper exploration of each technical practice by furnishing exhaustive lists of resources. I liked the checklist they provided containing guardrails while doing your refactoring. I think it acts as a useful guide for less experienced programmers but could also be a great starting point for discussions in your guild, chapter, or community of practice.

In the later chapters, the authors zoom in further on more detailed rules and principles that underpin the practices. I am not going to list them all; buy the book! Since I, at times, felt a little lost while reading my eBook, I recommend opting for the physical copy over the eBook version for a smoother reading experience and a better overview of the structure.

The book describes a limited yet crucial set of practices. Yet, the deep dive and the Katas make them applicable for developers. This book aims for developers to really embrace the practices. Additionally, I hope that the book triggers professionals to start talking about them. If you have the knowledge, share it in your community. This way, awareness is spread and gets shared with a larger group. Besides the three key practices that Pedro, Marco, and Alessandro distilled and described in their book, there are other practices that are worth knowing as well. I envision that books like this make organizations aware that effective value delivery is most likely obtained by proficient developers who know, talk about, and apply practices.