{"id":738,"date":"2021-07-06T09:35:32","date_gmt":"2021-07-06T06:35:32","guid":{"rendered":"https:\/\/hygger.io\/guides\/?p=738"},"modified":"2022-01-25T11:54:38","modified_gmt":"2022-01-25T08:54:38","slug":"technical-debt","status":"publish","type":"post","link":"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/","title":{"rendered":"Technical Debt"},"content":{"rendered":"<p><span data-preserver-spaces=\"true\">When you first hear the term &#8220;Technical Debt&#8221; in the Agile context, you may not immediately understand how this financial term relates to\u00a0<\/span><a class=\"editor-rtfLink\" href=\"https:\/\/hygger.io\/guides\/agile\/software-development\/\" target=\"_blank\" rel=\"noopener\"><span data-preserver-spaces=\"true\">Agile software development<\/span><\/a><span data-preserver-spaces=\"true\">. It is ok, no worries.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">When it comes to software development, Tech Debt (or TD) means that certain necessary work gets delayed during the development of a software project to hit a deliverable or a deadline.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">TD is the coding you must do tomorrow as you took a shortcut to deliver the software today. In this post, we give a Technical debt definition and take a deep dive into the concept of TD, exploring many related topics as well.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-21313\" src=\"https:\/\/hygger.io\/wp-content\/uploads\/2021\/07\/Agile-estimates.png\" alt=\"What is Technical Debt?\" width=\"1500\" height=\"900\" \/><\/p>\n<h2>What Is Technical Debt?<\/h2>\n<p>Technical Debt describes the situation when a development team speeds up the project delivery that will require refactoring later. The term is also known as tech debt, design debt, or code debt. This is about when a \u200bquicker development process becomes the priority instead of high-quality code.<\/p>\n<p>The Technical Debt metaphor is used in the technology space all over the world. It includes a catchall that covers everything from bugs to missing documentation and legacy code.<\/p>\n<p>However, why do we call it that way? In order to understand this, we should learn about the roots of the concept.<\/p>\n<h3>Where does the concept come from?<\/h3>\n<p><span data-preserver-spaces=\"true\">One of the authors of the famous\u00a0<\/span><a class=\"editor-rtfLink\" href=\"https:\/\/hygger.io\/guides\/agile\/manifesto\/\" target=\"_blank\" rel=\"noopener\"><span data-preserver-spaces=\"true\">Agile Manifesto<\/span><\/a><span data-preserver-spaces=\"true\">, Ward Cunningham, once compared some problems with code with financial debt. He said that it is ok to borrow against the future, as long as you pay it off. The author titled it \u201cTechnical Debt\u201d, and this metaphor has gained momentum.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">The main concept determines a serious problem that many software teams strive to manage. Ward Cunningham used it when he was developing a financial app in Smalltalk. The financial analogy was used as he wanted to justify to his boss the refactoring they were doing.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">In 1992, he provided additional details saying that shipping first-time code is like going into debt. Development can be increased by a little debt so long as it is paid back promptly with refactoring. And when the debt is not repaid, danger may occur. Interest on that debt is minutes spent on code that is not quite right for the programming task of the moment counts.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">When delivering code that is not right for the programming task of the moment, a development team incurs Technical Debt. It significantly decreases productivity, and such a loss is the interest of the Technical Debt.<\/span><\/p>\n<h3>Why this metaphor got popularity<\/h3>\n<p>The Tech Debt concept is a good way to communicate the need for refactoring and improvement tasks related to the source code and its architecture.<\/p>\n<p>If you can approximately estimate the time needed for fixing what is not right into your code, the principal of your debt, you are able to compare this info with the other project data. With this estimation, you will understand the overall situation and plan repayment activities.<\/p>\n<h2>Applying Tech Debt in Scrum\/Agile<\/h2>\n<p><span data-preserver-spaces=\"true\">The\u00a0<\/span><a class=\"editor-rtfLink\" href=\"https:\/\/hygger.io\/guides\/agile\/scrum\/\" target=\"_blank\" rel=\"noopener\"><span data-preserver-spaces=\"true\">Scrum<\/span><\/a><span data-preserver-spaces=\"true\">\u00a0framework has become extremely popular for software developers who try to deliver their products in a more efficient manner.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">Scrum has set principles, and one of them is that things are unpredictable: your clients change their minds, and new needs arise often. The openness to changes means that Technical Debt will likely occur when using Scrum.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">Two types of Tech Debt in Scrum can be defined:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">The active choice is to create a short-term solution that contains less-than-perfect code to let you deliver the product faster. It is expected that the dev team will go back and improve the code quality after the release.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">The other Tech Debt happens more passively as developers discover more valuable info about the problem they\u2019re trying to solve. As new needs arise, solutions that have worked recently may not work in the future. The code requires adjustment and refactoring. This contains a certain amount of debt.<\/span><\/li>\n<\/ul>\n<p><span data-preserver-spaces=\"true\">By the way, the Scrum Guide does not provide specific guidance regarding Technical Debt. However, accruing this debt is an essential part of the business, so teams should try their best to handle their code-based financials better.<\/span><\/p>\n<h3>How to handle it?<\/h3>\n<p><span data-preserver-spaces=\"true\">In order to handle it, Scrum teams should:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">Prioritize transparency with Tech Debt. This is what makes managing technical debt much simpler. Visualize the technical debt to keep it as a front-of-mind priority and review it during every Sprint meeting.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Monitor the debt. It is a good idea to count bugs and use more in-depth code metrics if possible.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Pay back debt regularly and quickly. Like with financial debt, it is better to manage technical debt when teams pay back their loans regularly.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Align product backlog. It should contain the tasks related to paying back Technical Debt.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Change the Definition of \u201cDone.\u201d Do not count something as finished until it meets a standard for manageable technical debt.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Standardize procedures. Generate a formula for how your team handles adding new features that include the introduction of tech debt.<\/span><\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-21314\" src=\"https:\/\/hygger.io\/wp-content\/uploads\/2021\/07\/yX14WLBBgDr6kLPhBR5dHApmfLokbMJqkNGACkS1.png\" alt=\"Technical debt and Agile\" width=\"1500\" height=\"900\" \/><\/p>\n<h2>Types of Technical Debt<\/h2>\n<p><span data-preserver-spaces=\"true\">People often argue about the differences of Technical Debt as it can take on various forms.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">There are two obvious types of Technical Debt: intentional and unintentional.<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">Intentional TD can be also called deliberate or active. It occurs when companies choose to leave room for improvement in their code for the sake of reducing time-to-market.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Unintentional TD is also called outdated, passive, or accidental. This type of Tech Debt happens when the code quality needs improvement after a period of time. It can be the result of weak production the first time around or simply the natural need for updates when code becomes outdated.<\/span><\/li>\n<\/ul>\n<p><span data-preserver-spaces=\"true\">In 2014, the authors of \u201cTowards an Ontology of Technical Debt\u201d proclaimed that companies would be better served if their Tech Debt had more specific categories. So, they proposed 13 types of Technical Debt. Each type includes the specific problem within the title. Here they are:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">Architecture Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Build Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Code Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Defect Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Design Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Documentation Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Infrastructure Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">People Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Process Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Requirement Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Service Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Test Automation Debt<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Test Debt<\/span><\/li>\n<\/ul>\n<p><span data-preserver-spaces=\"true\">All these types have their own specifics but the most famous way of categorizing TD comes from the Technical Debt Quadrant.<\/span><\/p>\n<h2>What Is the Technical Debt Quadrant?<\/h2>\n<p><span data-preserver-spaces=\"true\">In 2009, the twofold separation of intentional and unintentional technical debt was nuanced by Martin Fowler.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">Like Cunningham, Fowler was one of the 17 authors of Agile Manifesto. He understood that people used the metaphor of Tech Debt to ask the wrong questions.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">Instead of digging out the answer to tech questions about design flaws, Martin strived to know if the debt these software systems accumulated was reckless or prudent. This distinction and the idea of deliberate\/inadvertent debt formed the basis of the Technical Debt Quadrant.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">This quadrant creates four types of Tech Debt:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">Reckless\/Deliberate<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Reckless\/Inadvertent<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Prudent\/Deliberate<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Prudent\/Inadvertent<\/span><\/li>\n<\/ul>\n<p><span data-preserver-spaces=\"true\">Is it easy to realize the difference between the prudent and the reckless?<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">The prudent team understands the moves they make and use their Technical Debt intentionally.<\/span><\/p>\n<p><span data-preserver-spaces=\"true\">The reckless team uses their software system like a cardholder during shopping, and the debt just keeps coming.<\/span><\/p>\n<h2>Technical Debt Metrics: How to Analyze TD?<\/h2>\n<p>If you cannot measure Tech Debt, then knowing a lot about the debt does not really matter. As with any effective management plan, companies need to know the best metrics to gain control over their TD. Here are some of the most efficient metrics:<\/p>\n<h3>1. Bugs<\/h3>\n<p>Developers should count and keep track of their bugs at least. This includes fixed and unfixed bugs. Noting the unfixed bug lets software developers fix them during their Agile iterations. Catching the fixed bugs allows them to measure how effective their TD management process is.<\/p>\n<h3>2. Code quality<\/h3>\n<p>While bugs directly affect software end-users, code complexity can damage the development team and the entire company.<\/p>\n<p>It&#8217;s better to consider such code complexity metrics as cyclamate complexity, lines of code, class coupling, the depth of Inheritance, etc. The lower each measure is, the better.<\/p>\n<h3>3. Code cohesion<\/h3>\n<p>Intensified focusing on code cohesion will make the code less complex in the end. High code cohesion typically means that the code is more reusable and maintainable. It also minimizes the number of people involved in coding.<\/p>\n<h3>4. Code ownership<\/h3>\n<p>More engineers mean more cruft. More cruft may lead to greater problems and higher levels of unintentional Tech Debt.<br \/>\nThis metric allows project management to see the number of people working on different code pieces.<\/p>\n<h3>5. Churn<\/h3>\n<p>Code &#8220;churns&#8221; appear when code gets replaced or rewritten, for example. It is important to pay special attention to code that is extremely active because any problem in there will be exacerbated.<\/p>\n<p>Measuring churn will you help to recognize and prioritize what parts of the code require refactoring. If there is a need to constantly address bugs around the same part of the code, then something is going wrong over there.<\/p>\n<h3>How to identify Technical Debt<\/h3>\n<p><span data-preserver-spaces=\"true\">Some warning signs demonstrate that your project has created Tech Debt:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">When code seems much more subtle than logic errors. It indicates problems that are more likely to impact overall performance quality than cause a crash.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">When the product has bugs that will cause an entire system crash.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">When there are higher complexity levels (when technologies overlap each other).<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">When there are issues with a coding style that can be handled by developing a coding style guide and sticking to it.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">When there are non-functional requirement issues where the code violates an NFR restraint.<\/span><\/li>\n<\/ul>\n<p><span data-preserver-spaces=\"true\">When you leave these essential things unaddressed, it can result in:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">Reduced agility<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">The higher total cost of ownership<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Negative customer experience<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Longer time to market<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Poor security<\/span><\/li>\n<\/ul>\n<h3>Good and bad reasons for Tech Debt<\/h3>\n<p>Like financial debt, there can be good reasons for TD. However, it is important to know that going in, so debt does not get ahead of the team, slowing down progress and future deliveries.<\/p>\n<p>Delivery is more important than internal code cleanliness, and it is an essential reason for incurring Tech Debt. When the product works for the user (despite not being the best or the cleanest one), then delivery can bring the company a lot more in terms of revenue and time to market than what they lose in code perfection.<br \/>\nA bad reason for holding TD is when the team chose to focus on other areas that can be more innovative but less important.<\/p>\n<p>Development teams must be balanced. It is important to look at many sides of the issue to define how much Tech Debt is fine.<\/p>\n<h2>What Are the Best Practices in Managing Technical Debt?<\/h2>\n<p>There are some reliable ways to manage Technical Debt:<\/p>\n<h3>1. Assessing<\/h3>\n<p>The process of identifying TD may be accompanied by some key signals. For example, the performance ratings of the product can be reduced or developers can need much longer to iterate. How to measure this? What is the real cost of Tech Debt?<\/p>\n<p>To measure TD, you can look at the number of days developers would need to spend reducing TD by performing activities like refactoring or replacing the app. After attaching a dollar amount to these functions, you may compare this data to other milestones, (for example, the number of remaining days before the release date). It will help you to make your cost\/benefit analysis more effective.<\/p>\n<h3>2. Communicating<\/h3>\n<p>It is also crucial to understand that TD exists in the first place and share that discovery with the stakeholders. IT management should communicate to non-IT managers about the true cost of Tech Debt. And the head of IT should be responsible for explaining the importance of paying down Technical Debt sooner than later.<\/p>\n<h3>3. Paying off<\/h3>\n<p><span data-preserver-spaces=\"true\">You can pay Technical Debt using one of the following options:<\/span><\/p>\n<ul>\n<li><span data-preserver-spaces=\"true\">Completely waive the requirement. It means the company decides to live with the system as it is and no longer considers the requirement necessary.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Refactor the app. This is about reducing complexity, removing duplicates, and improving the structure of the code.<\/span><\/li>\n<li><span data-preserver-spaces=\"true\">Replace the app. This will probably lead to a new TD, but the idea is to address it quickly and minimize it.<\/span><\/li>\n<\/ul>\n<h3>How to minimize Technical Debt with Agile practices?<\/h3>\n<p>The term \u201cdone\u201d is quite relative, and every Agile practitioner knows that. In traditional development, the software is done when it is delivered to end-users. However, in Agile, work iterations are frequently delivered to users, improving issues and bugs that develop in each release. So, there is no \u201cdone\u201d.<\/p>\n<p>Instead of promoting multiple functions in a release, Agile assumes reducing the scope of a release to ensure quality work. It embraces iterations and increments instead of finished projects, that is why implementing Agile theories can be a great way to stay on top of Tech Debt.<\/p>\n<p>IT teams think in short bursts of work, and this helps them to tackle smaller groups of TD continuously. Therefore, Debt is not forgotten for bigger projects and phases as well.<\/p>\n<h4>Conclusion<\/h4>\n<p>Changing the philosophy of your team on how to manage Technical Debt isn&#8217;t easy. Sometimes companies need to cut development time short in order to get to market sooner. With that in mind, educate your product owner on the real cost of TD, modularize your architecture, and write automated tests.<\/p>\n<p>Remember that Tech Debt is a reality for all software teams. No one can avoid it entirely. The key thing is to keep it from spiraling out of control.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When you first hear the term &#8220;Technical Debt&#8221; in the Agile context, you may not immediately understand how this financial term relates to\u00a0Agile software development. It is ok, no worries. When it comes to software development, Tech Debt (or TD) means that certain necessary work gets delayed during the development of a software project to [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":342,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"class_list":["post-738","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-development"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v16.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<meta name=\"description\" content=\"A quick guide on how to reduce technical debt.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What is Technical Debt? - Hygger.io Guides\" \/>\n<meta property=\"og:description\" content=\"A quick guide on how to reduce technical debt.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/\" \/>\n<meta property=\"og:site_name\" content=\"Hygger.io Guides\" \/>\n<meta property=\"article:published_time\" content=\"2021-07-06T06:35:32+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-01-25T08:54:38+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/hygger.io\/guides\/wp-content\/uploads\/2021\/04\/agile.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1400\" \/>\n\t<meta property=\"og:image:height\" content=\"300\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\">\n\t<meta name=\"twitter:data1\" content=\"11 minutes\">\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/hygger.io\/guides\/#website\",\"url\":\"https:\/\/hygger.io\/guides\/\",\"name\":\"Hygger.io Guides\",\"description\":\"Hygger: Project Management Software &amp; Tools for Companies\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/hygger.io\/guides\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/hygger.io\/guides\/wp-content\/uploads\/2021\/04\/agile.png\",\"contentUrl\":\"https:\/\/hygger.io\/guides\/wp-content\/uploads\/2021\/04\/agile.png\",\"width\":1400,\"height\":300,\"caption\":\"Agile\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/#webpage\",\"url\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/\",\"name\":\"What is Technical Debt? - Hygger.io Guides\",\"isPartOf\":{\"@id\":\"https:\/\/hygger.io\/guides\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/#primaryimage\"},\"datePublished\":\"2021-07-06T06:35:32+00:00\",\"dateModified\":\"2022-01-25T08:54:38+00:00\",\"author\":{\"@id\":\"https:\/\/hygger.io\/guides\/#\/schema\/person\/cab80745946cdf5feea0cee70ab6cffc\"},\"description\":\"A quick guide on how to reduce technical debt.\",\"breadcrumb\":{\"@id\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/hygger.io\/guides\/\",\"url\":\"https:\/\/hygger.io\/guides\/\",\"name\":\"\\u0413\\u043b\\u0430\\u0432\\u043d\\u0430\\u044f \\u0441\\u0442\\u0440\\u0430\\u043d\\u0438\\u0446\\u0430\"}},{\"@type\":\"ListItem\",\"position\":2,\"item\":{\"@id\":\"https:\/\/hygger.io\/guides\/agile\/software-development\/technical-debt\/#webpage\"}}]},{\"@type\":\"Person\",\"@id\":\"https:\/\/hygger.io\/guides\/#\/schema\/person\/cab80745946cdf5feea0cee70ab6cffc\",\"name\":\"Pavel Kukhnavets\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/hygger.io\/guides\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/1c304a131d7d560805a98b095abf6816b67434834ab4109340b1e6dfa4061a1b?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/1c304a131d7d560805a98b095abf6816b67434834ab4109340b1e6dfa4061a1b?s=96&d=mm&r=g\",\"caption\":\"Pavel Kukhnavets\"},\"description\":\"Pavel is a Content Marketing Manager at Hygger.io &amp; Welldoneby.com, a project management tool loved both by tech and non-tech people. Pavel writes about the world of Agile project management, covering such topics as popular methodologies, frameworks, techniques, innovative tools, and much more that affect the overall efficiency and productivity of product teams.\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/posts\/738","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/comments?post=738"}],"version-history":[{"count":6,"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/posts\/738\/revisions"}],"predecessor-version":[{"id":1134,"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/posts\/738\/revisions\/1134"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/media\/342"}],"wp:attachment":[{"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/media?parent=738"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hygger.io\/guides\/wp-json\/wp\/v2\/categories?post=738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}