The Agile Wilderness: Principle #9: Technical Excellence

Agile Principle #9: "Continuous attention to technical excellence and good design enhances agility." (1)

Image from medium.com (2)

I think this is one of the most over-looked principles out of the 12. Sadly, many developers and quality assurance folks have had a bad experience with "Agile" because technical excellence is not considered, and they are just forced to "do things faster" and "not worry about architecture". When you consider who created the agile manifesto, this is hard to believe and shows that we went off track along the way somewhere.

Digging into the agile principle

I think there are a few parts of this principle to note. One is the "continuous attention" which in my mind means you are thinking about this every increment or even every story. The other part is that technical excellence and good design allows you to be more agile and respond to change.

"Continuous attention" means that everyone is talking and thinking about technical excellence and good design. This means that we have our architects working with our business partners from the beginning thinking and talking about trade-offs we are making as we build things and incorporating enabling work to prepare us for the future. This means the product owner is working with the developers to understand if we take any short cuts along the way so we can prioritize and fix the technical debt in our product before it gets too big, and we are unable to move quickly. This means the team talks about and measures the technical excellence and good design of the product and continues to try to make it better every day. This could be from minor refactoring within other work being done to major re-architectures worked on across several teams.

Technical excellence and good design enhance agility by making sure the foundation of what we are building can support where we may want to go with our product. When we get into cycles of just pumping things out, we tend to get into a bad place where it is very difficult to change what we have built and therefore are unable to be agile in responding to the market's needs. If we do not build something of quality, it is much more difficult to change. Taking short-cuts for a long time will lead you to a place where you have a mountain of technical debt that you are unable to get out of. Also, If we do not think about the design with the product vision in mind we can "paint ourselves into a corner" where we are unable to make the changes we want to a product without significant refactoring or re-architecture.

I usually see organizations who are serious about technical excellence and good design consider practices from XP such as TDD/BDD and/or pair programming. (3) These practices focus on giving development the focus needed to build quality software that is not going to break when we try to change it. I am not going to go into all of these practices here, but I encourage you to google them and reach out if you have questions.

Comparing the agile principle to Scrum values and SAFe scaled principles

As we look to the Scrum values that apply to this principle, Courage and Openness come to mind. (4) As with many of the other principles we need to have a trusted relationship across our team and stakeholders to talk through important topics. In this case, we need to have the courage to speak up about technical debt and decisions we are making around technical excellence and design. We also need to be open with each other about how these decisions effect our ability to be agile.

Next, let's look at the Scaled Principles that apply and relate to this idea of continuous attention to technical excellence and good design as we scale. These include 2,3 and 9 which are applying systems thinking, assumer variability; preserve options, and decentralized decision making respectfully. (5)

Applying systems thinking allows us to see how what we do effects other parts of the organization and is something that needs to be considered as you scale, specifically as you define the vision for your product and the design you plan to use. (6)

Assume variability and preserve options makes sure as we build our foundation of our product with flexibility to change for the future needs of our customers. This is something that is a continuous discussion as we continue to learn from the product we build.

Decentralized decision making is key as you scale because we want to move quickly and have the people with the most information making the decisions about the product they are building. As discussed earlier, we need to apply systems thinking and have design considerations for how what we do affects others in the organization but the ability to make decisions closer to the work increased the technical excellence and quality of the product we build.

Suggested changes to the original agile principle

"... good design enables agility."

Without continuous attention to technical excellence and good design organizations are unable to be agile and therefore I think there needs to be slightly stronger language used in the principle here, specifically enables agility instead of just enhances it.

Closing

In closing, an agile mindset promotes continuous attention to technical excellence and good design. Without it organizations will struggle to keep up and make the changes they need to within their products. Here is a quick summary of the comparisons and changes I would suggest for agile principle 9:

I hope you have enjoyed this article and as always feel free to reach out to discuss further or drop a comment below to join the discussion. Thank you for your time and look forward to sharing my thoughts about "Principle #10: Simplicity" next time.

About the Author

Jeff Mortimer?(#theAgileMoose) is an Agile Enthusiast with over 10+ years of experience working in various roles on agile teams including business analyst, product owner, scrum master, team leader, technical delivery manager and now an agile coach consultant focused on product transformations. In additional to his certifications in CBAP, AAC, CSP-PO, SAFe Agilist and SAFe LPM, Jeff?has presented at several conferences throughout North America and joined the blogger universe a couple years ago to bring a voice to the everyday agile practitioners. He also just received his EMBA at Quantics School of Business and Technology. He is a husband to an amazing intelligent wife who has her doctorate in math education, father to kids who bring him joy every day, friend that brews beer and plays soccer, and citizen who helps organize volunteers to give back to the community.

Follow #theAgileMoose for the latest insights in the agile wilderness.

References

(1)?Agile Principles from agile alliance

(2) Principles Image from medium.com

(3) 12 core practices in XP from c-sharcorner.com

(4)?Scrum Values ?from scrum.org

(5)?SAFe Scaled Principles ?from scaledagileframework.com

(6) How system thinking enables design thinking by bootcamp