Building Blocks to Technical Agility

The DevOps movement brought attention to the value of Continuous Delivery. Organizations began hiring Technical Coaches to "stand up a CI/CD pipeline." Technical Coaches, most of whom had backgrounds in eXtreme Programming, were lukewarm to this directive. They felt that their role was to introduce quality and discipline into the development process through Test-Driven Development (TDD). Neither the CTOs nor the coaches were correct, as both Continuous Delivery and TDD are advanced practices that require mastery of foundational building blocks.

In 2014, Arlo Belshee, inspired by the Shore/Larson Agile Fluency Model, created the Agile Engineering Fluency Stages of Practice Map. In his model, he defines a progression of the specific practices that a team must master to gain fluency in the Delivering Zone. Belshee defines 6 stages of practice:

1. Traditional done well

2. Work as a team

3. Core modern engineering

4. Adaptive engineering

5. Leverage capabilities

6. Eliminate debt and change the rules

7. Take advantage of being awesome

A team in the Focusing Zone is generally fluent in the 2nd stage (Work as a team) and ready to embark on the 3rd (Core modern engineering). TDD (which Belshee calls "the rapid coding inner loop") sits on the cusp between the 5th (Leverage capabilities) and 6th (Eliminate debt and change the rools) stages. Continuous Delivery is in the 7th stage (Take advantage of being awesome).

Why can't we jump to Continuous Delivery?

Continuous Delivery represents the promise of DevOps, which is shipping at will. Belshee defines various value streams in his model, one of which is the Ship at will stream. Within the Ship at will stream, Continous delivery depends on various DevOps practices, such as Feature isolation, Automated rollback, Automated deploy verification, Sustainable automated deploy and Automated build verification. The model points out, however, that Continuous delivery also has a cross-dependency from the Write good code stream, namely the practice that Belshee calls #BugsZero. The rationale is simple. If we cannot be confident in a bug-free code base, our CD pipeline with continuously deliver crap. And #BugsZero depends on many other technical practices, including TDD.

Why can't we just teach TDD?

TDD is the sexy part of eXtreme Programming. XP developers attest to the dopamine rush that comes whenever the red bar turns green. The problem is that TDD consists of three steps: Red-Green-Refactor. GREEN is the easy part, and it is the one that produces the dopamine. RED and REFACTOR are difficult. RED requires testing skills that are mastered in stages. First the team must develop a "prove it" mindset and practice automated developer testing. Then the team can improve the quality of its tests with the recognition that a test is a spec. Once the team learns to code in small, testable units (a skill that depends on some refactoring skills -- see below), they will be able write fast, consistent, automated tests. Only then will they have the testing skills needed for effective TDD.

REFACTORing skills are similarly staged. First developers must develop muscle memory in Local, Transform-based Refactoring, the CRUD operations of Extract, Inline and Rename. They can then learrn to practice the 4 rules of Simple Design, eliminating duplication through Don't repeat yourself and expressing intent through Naming is a process/Safely modify legacy code. Finally, the team can apply these skills to Reflexive design, which will allow them to effectively refactor during TDD.

Work together, learn together, grow together

These testing and refactoring skills will take hold only on a team that has a firmly established collaboration and growth culture. First they must embrace Shared task responsibility, the mindset that they are not just a "work group" but a team. They then must adopt a collaborative development (pairing/mobbing) agreement, so that they can work together to learn. Through collaboration, they will propogate their skils and become T-shaped people. The team must adopt a tight cycle of Iterative team improvement, where they are always running measurable experiments. Once a team as assumed full control of its learning and its growth, it can truly embrace Collective ownership, which opens the doors to the really cool stuff.

The building blocks

To summarize, the foundational building blocks of Technical Agility are

• Collaborative development

• Continous improvement

• Refactoring

• Testing

.A team that has built fluency in these building blocks (each of which contains its own progression of practices) will be able to reap the value of TDD and finally of Continuous Delivery.

At Agile Tech, we focus on the Building Blocks. We meet teams where they are on their journey, and we guide them to technical agility, one step at a time. Please let us know how we can help.