Continuous attention to technical excellence and good design enhances agility. — Agile Principle #9

A well-designed Agile process for development pulls technical excellence from teams wherever it is applied, by making the Agile process more effective in ways that visibly benefit the team and the organization.

The astounding growth of DevOps, with better architecture standards, more automated tools for regression testing and the movement towards test-first development in software shows how this has manifested in software development, even among people who are hacking out a Minimum Viable Product for a startup.

I’ve also seen the same effects among teams using Rapid Learning Cycles. I’m working now with a company that fully adopted Rapid Learning Cycles in 2017. Now, 5 years later, they have an entirely different and better set of problems to solve to get to the next level of product development performance, driven by their desire to increase capacity for even more innovation. They are hungry to improve their technical excellence, especially in Advanced Development and in HW / SW Integration, because that’s now their constraint.

Three Ways Agile Drives Technical Excellence

Agile is not known for the things people associated with technical excellence in the past, like pages of documentation, code reviews, detailed architecture designs and requirements analysis. But Agile software teams learn quickly that practices like daily builds, coding standards and test-driven development help them get more from the principles of agility.

Good agile processes — ones that focus on applying the principles of Agile appropriately for the problem domain — pull technical excellence out of software teams in three ways:

• Makes the team’s progress more real, and more visible. Agile software teams plan their work for a Sprint by estimating how long it will take to complete a User Story. Then they use a burn down chart to track their progress, only marking a story complete when it is done-done. The slope of that line is the team’s velocity. This makes the team’s real progress visible and encourages them to get the obstacles out of their way that are slowing them down, by improving their operations. We also see this in the hardware space among teams using Rapid Learning Cycles: the knowledge they build to close Knowledge Gaps is much more visible to the team and to their management, as is the progress they make towards better Key Decisions.
• Allows team members to help each other. When the team uses coding standards and test-driven development, it’s easier for one team member to jump in and help out another team member. This dynamic plays out differently for physical products, where teams usually have more defined disciplines and roles. While they can’t help each other out by taking on each other’s work, they can help each other out by working together to delay Key Decisions and close Knowledge Gaps where their systems interface.
• Highlights the value of good architecture decisions. When a software team is working within a well-architected framework, the User Stories and other work have many fewer dependencies. This lowers the cost-of-change and allows the Product Owner to choose User Stories based on value instead of technical constraints. For physical products with inherently high cost-of-change, good architecture decisions drive down uncertainty, reducing the number of Knowledge Gaps that the team needs to close by moving more decisions from the high-unknown Key Decision category to the Known Solution category.

Across the board, when we break up work into smaller pieces, continuously deliver value and frequently review real progress, any design flaws and defects come to the surface sooner, when they are easier to fix.

Technical Excellence Leads to Known Solutions with Low Risk

Some types of physical product development lend themselves to modular architectures, with interfaces that are Known Solutions, allowing components to be swapped out with little risk. Most of us are reading this article on such a physical product: computers and mobile devices have driven modularity to this level. The chips, screens, battery, power supplies, fans, etc. are all modular units, which is why Apple can sell over a dozen different iPhones with different screens, memory and chip sets, and why I was able to configure my MacBook Pro to get the upgrades I wanted without paying for stuff I didn’t need.

A good Agile process will eventually lead a team towards modular architecture because it makes the rest of the Agile practices work so much better. Physical product teams experience this as fewer, more focused Knowledge Gaps to close and faster integration with fewer failures at the system prototype level. They can pull more work into Advanced Development teams to evolve individual modules. Then product teams move quickly to integrate new modules into their product designs after the new content has been proven to work at a subsystem level.

Since the Advanced Development teams have been using Rapid Learning Cycles all along, they have been capturing the knowledge they need to hand off their modules to a team responsible for product design, which is now mainly integration plus industrial design, and the transition to manufacturing. While Knowledge Gap and Key Decision reports cannot replace all of the knowledge transfer, it gives both sending and receiving teams a better place to start their conversations.

Technical Excellence and Agile Reinforce Each Other

The authors of the Agile Manifesto saw that teams operating at a higher level of technical excellence were able to maximize the value they received from the Agile principles and practices. I’d argue that it works the other way, too: Agile pulls technical excellence from the teams.

“Agility and technical excellence support each other: technical excellence and good design enhances agility, as the drive for agility reinforces the need for technical excellence.”