My Fascination with Agile and Technical Debt
Charles Meyer Richter
Principal information architect & diagnostician at Ripose Pty Limited
Preamble
This transcript was the result of my reading a LinkedIn post by Jesper Lowgren on the subject of Technical Debt and my exchange of views with a LinkedIn member (a Tom Mellor) who accused me of not knowing anything about Technical Debt and based his proof by providing me with a video by Howard G. Cunningham on the subject of the “Debt Metaphor” which was published 16 years ago. He as now deleted all his his responses.
As an Information Architect I am always fascinated by the claims made by theorists about a subject that no one really understands.
In order to explain why the theories regarding the failure of Agile to address Technical Debt by using a project management approach to address a small component of Business Requirements and treating it as an Agile Sprint with SCRUMs which in turn results in “a failure to communicate” (a quote from the movie Cool Hand Luke and a Critical Failure Factor which is the antithesis of the Critical Success Factor (aka ‘Values’) I had to use Microsoft Copilot AI engine to answer a number of questions (in the Appendix) in order to arrive at my Conclusion:
As my article is 6 pages long please read it by following this link.
Regards
ps I have also updated my fascination article to include this one.
Senior Software Architect & Principal Engineer
1 周This is an interesting perspective. I agree that not knowing what we do not know or distortions when communicating lead to product and technical debts. The question is: How could we know better? Gathering the necessary information (timely) hasn't proven easy, especially if we do not know what to ask or if there are no domain/business experts to answer our questions. Agile methodologies try to find ways to move forward even if we do not have enough information and are accepted as the de facto standard in the software industry. That is the ethos around moving fast and breaking things until we figure it out. After so many years of dealing with delayed and partially successful software projects, we must learn to deal with the lack of information and the business pressure to deliver results (not the same as value in some cases). I will read more on the Ripose Information Architecture theory and see how it can help during software projects.?Thanks.