add Project Management and Technical Debt

Technical-Debt.md

@@ -6,14 +6,18 @@
 
 - [Dealing with Technical Debt Like We Mean it](https://medium.com/@GeneHughson/dealing-with-technical-debt-like-we-mean-it-155a98a39f1c) - by Gene Hughson. "...assessing and managing technical debt should be an ongoing activity with a responsible owner rather than a one-off event that “somebody” will take care of. The alternative is a bit like using a credit card at every opportunity and ignoring the statements until the repo-man is at the door."
 
+- [Doc Norton Sez You’re Using “Technical Debt” Wrong at Agile2016](https://www.solutionsiq.com/resource/agile-amped-podcast/doc-norton-sez-youre-using-technical-debt-wrong-at-agile2016/) (Video) - by SolutionsIQ. "In short, “technical debt” isn’t code that you intend to clean up later: it’s clean code created when the dev’s knowledge is impartial that the dev can then easily refactor when they learn more about the problem. The danger with the current meaning of technical debt is that the term is benign enough that we don’t give it enough attention. “In a great extent, we’re using the metaphor to abdicate our own professional responsibility…” Things that teams can start doing now: create debt stories and discuss with the business what the real value of that debt is."
+
 - [How to deal with technical debt and save your sanity](https://medium.freecodecamp.org/tame-your-tech-debt-by-refactoring-more-often-fcc34dd24a33) - by Gabriel Colombo. "Each project should have a set of standards, so that everyone knows how they should do things. These standards should always matter while there’s people working on the project."
 
-- [Doc Norton Sez You’re Using “Technical Debt” Wrong at Agile2016](https://www.solutionsiq.com/resource/agile-amped-podcast/doc-norton-sez-youre-using-technical-debt-wrong-at-agile2016/) (Video) - by SolutionsIQ. "In short, “technical debt” isn’t code that you intend to clean up later: it’s clean code created when the dev’s knowledge is impartial that the dev can then easily refactor when they learn more about the problem. The danger with the current meaning of technical debt is that the term is benign enough that we don’t give it enough attention. “In a great extent, we’re using the metaphor to abdicate our own professional responsibility…” Things that teams can start doing now: create debt stories and discuss with the business what the real value of that debt is."
+- [Introduction to the Technical Debt Concept](https://www.agilealliance.org/introduction-to-the-technical-debt-concept/) - by Agile Alliance. "The Technical Debt concept is an effective way to communicate about the need for refactoring and improvement tasks related to the source code and its architecture."
 
 - [Managing Technical Debt](https://www.scrumalliance.org/community/articles/2013/july/managing-technical-debt) - by Srinath Ramakrishnan. "The key to managing technical debt is to be constantly vigilant, avoid using shortcuts, use simple design, and refactor relentlessly. Unchecked technical debt makes the software more expensive to modify than to reimplement."
 
 - [Paying Off the Technical Debt in Your Agile Projects](https://www.agileconnection.com/article/paying-technical-debt-your-agile-projects) - by Nishi Grover Garg. "Every team has to devise its own strategy to prevent technical debt from accumulating, but a universal best practice is to have a definition of “done” in place for all activities, user stories, and tasks, including for completing necessary testing activities. A definition of “done” creates a shared understanding of what it means to be finished so that everybody involved on the project means the same thing when they say it's done. It becomes an expression of the team's quality standards, and the team will become more productive as their definition of “done” gets more stringent."
 
+- [Project Management and Technical Debt](https://www.agilealliance.org/project-management-and-technical-debt/) - by Agile Alliance. "Every team has to make decisions about where to start addressing technical debt. Ultimately, you need to create a working agreement within the team that covers how you assess and resolve technical debt."
+
 - [Technical Debt: Adding Math to the Metaphor](http://reinertsenassociates.com/technical-debt-adding-math-metaphor/) - by Donald Reinertsen. "When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work. In finance the concept of deferral is well understood. There are economic reasons for deferring revenues and expenses; managers are familiar with deferred assets and deferred liabilities. Calling it deferred work captures the economic essence of what we are doing without any positive or negative connotation."
 
 - [Technical Debt – or Technical Bankruptcy?](https://www.extremeuncertainty.com/technical-debt-technical-bankruptcy/) - by Leon Tranter. "The fact that we have so many systems so badly riddled with technical debt is embarrassing. It almost always happens because developers are not allowed to do their jobs properly. They are mistrusted and micro-managed by people with little real understanding of IT finance and less understanding of engineering. We have to stop technical bankruptcy and we can do it by following simple, trusted practices of software craftsmanship. If we don’t, the technical debt will come back to haunt us, and cost us many more times than whatever money we saved by cutting corners in the first place."