Scrum and Kanban

Scrum and Kanban

What is the Agile Scrum Framework? How is it different from the Kanban approach. If you are applying the Scrum framework and leveraging the Kanban board, you might be thinking that Scrum and Kanban are the same. In addition, you might be wondering which methodology is a better fit for your work.

In this article, I have listed the core differences between Scrum and Kanban. Moreover, I also covered which framework is best suited with different type of work or teams.

Scrum in a nutshell

Scrum is an iterative and incremental Agile process framework to build complex products of the highest possible value. In Scrum, the team always works on the highest priority items first. The work is performed in short, time-boxed iterations or sprints. Each sprint begins when the team commits to complete prioritized user-stories based on their available capacity in the sprint. An iteration ends when the team has delivered a potentially shippable product increment of the product. Therefore, the scrum development team delivers business value to users at the end of each sprint.

The three Scrum roles - Product Owner, Scrum Master, and the Development Team - are defined below: 

  • A Product Owner decides what needs to be built and in what order.
  • A Scrum Master acts as a servant leader and coaches the team to follow Agile Scrum principles.
  • A Development Team is a group of self-organizing individuals who develop a high-quality product.

Scrum requires the below ceremonies to be conducted on a regular cadence:

  • Product Backlog Refinement
  • Sprint Planning
  • Daily Stand-Up
  • Sprint Review
  • Sprint Retrospective

Above all, Scrum is most suited for complex projects where things are more unpredictable than they are predictable. In complex domains, there is a need to collaborate with others, have an innovative mindset to investigate, experiment with different ideas, and adapt based on the learnings.

To learn more about Scrum, you may read my book, The Basics Of Scrum – A Simple Handbook to the Most Popular Agile Scrum Framework. 

Kanban in a nutshell

Kanban is the most popular Lean framework. This approach works best for teams that have a continuous flow of incoming requests with different priorities. In the Kanban approach, each request or a work item is represented by a Kanban card that flows from one stage of the workflow to another until it is complete.

Kanban is very flexible in nature. New work items can be added to the backlog at any time. Even the workflow can change anytime. If team capacity changes, WIP limits get recalibrated. In addition, Kanban does not prescribe any roles or ceremonies. It optimizes an existing process by eliminating waste and improving time to market.

To learn more about Kanban, you may read my other book, The Basics Of Kanban - A Popular Lean Framework

Compare Scrum and Kanban

Below section lists the core differences between Scrum and Kanban:

  • Scrum was formulated for complex product development to mitigate the limitations with the traditional Waterfall approach. Kanban, on the contrary, originated to manage work and control inventory at Toyota with Just-In-Time and Lean principles.

 

  • Scrum prescribes product teams to manage work within time-boxed, short, and consistent length iterations or sprints. However, Kanban specifies a continuous flow of work across different states.

 

  • With Scrum, development teams create a potentially shippable product increment at the end of every sprint. Therefore, teams can release code at the end of every sprint if approved by the product owner. With Kanban, teams can release code anytime or on-demand. 

 

  • Scrum requires three roles - Product Owner, Scrum Master, the Development Team. Kanban, on the other hand, does not prescribe any specific role.

 

  • In Scrum, the smallest piece of business value that a team delivers is a user story. Each user story may then be broken down into smaller tasks or sub-tasks. However, in Kanban, each work item is represented as a Kanban card.

 

  • Scrum is best suited for complex product development efforts that are unpredicatable in nature. Such complex efforts require research, experimentation, and an emergent design. Kanban, on the contrary, is best suited for simple and complicated efforts where things are more predictable than they are unpredictable.

 

  • With Scrum, sprint review and retrospective ceremonies are conducted at the end of every sprint to inspect and adapt. Though Kanban does not prescribe any ceremonies, teams may conduct a review meeting on a monthly or a quarterly cadence to review cycle time, flow efficiency, etc.

 

  • Scrum prescribes user stories to be estimated in terms of story points. However, Kanban does not require work items or Kanban cards to be estimated. In Kanban, estimation is optional. Some teams choose to estimate their work to have more predictability while others prefer to split their cards such that each of the cards is of the same size.

 

  • With Scrum, the most popular metrics are sprint burndown and velocity. Other useful metrics are release burndown, release burnup, and sprint burnup. The most popular Kanban metrics is cycle time. Metrics such as lead time, throughput, cummulative flow diagram (CFD), and control charts are also leveraged.

 

  • Kanban has more flexibility than Scrum as new work items can be added to the workflow at any time. 

 

  • Scrum prescribes ceremonies to be conducted on a regular cadence. For instance, the sprint planning ceremony must be conducted at the start of each sprint. Sprint review and retrospective ceremonies must be conducted at the end of each sprint. In addition, the daily stand-up must be conducted each day of the sprint. However, Kanban does not prescribe any cadence or ceremonies to be conducted. In Kanban, meetings are held as needed.

 

  • With Scrum, additional or new user stories should not be added to the active or an ongoing sprint. However, in Kanban, new work items or cards can be added anytime, provided the WIP (Work-In-Progress) limit hasn't reached yet.

 

  • In Scrum, the sprint backlog is reset after every sprint. However, the Kanban board is continuous.

 

  • To adopt Scrum, enterprises need to develop an agile mindset. Scrum requires a considerable change to the existing organizational structure and processes. As a result, leaders invest into Scrum training and create new roles or positions to build the best Scrum teams. On the contrary, Kanban does not require any significant changes to onboard onto this framework.

 

Now that you understand the differences between the two frameworks, you can decide which approach works best for your team. For more on Agile, Lean, Scrum, or Kanban, you may read below books:

Please follow and like us:
error

Agile and Lean

Agile and Lean - Same or Different?

Agile and Lean

You might ask whether Agile and Lean are the same or different. Which one is the best methodology for your business? Below are my views on the main similarities and differences between the two.

Similarities in Agile and Lean 

The core similarities between Agile and Lean are listed as follows:

Development approach

Lean development encourages to limit the work-in-progress (WIP). Agile methodology also promotes incremental development within short, time-boxed iterations. Both methologies have a similar approach to reduce the batch size. 

Continuous Improvement

Lean is very focused on Kaizen or continuous improvement. Agile, too, encourages inspect and adapt activities (such as product demo and retrospectives) that promote continuous improvement. 

Collaboration

Teamwork is one of the core values defined in Toyota Way 2001. Lean methodology encourages collaboration between team members. Agile methodology also focuses on collaboration (refer to the two statements from the Agile Manifesto below):

  • Individuals and interactions over processes and tools
  • Customer collaboration over contract negotiation

One of the 12 Agile principles, ‘Business people and developers must work together daily throughout the project.’ highlights the significance of teamwork and collaboration. 

Customer-centric approach

Lean is a customer-centric methodology. It delivers the best quality work in the shortest sustainable lead time. Similarly, Agile is customer-centric as well. For instance, the 1st Agile principle, ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’ is customer-focused.

Just-in-Time (JIT) approach

With Just-in-Time (JIT) approach, teams build only what is needed, when it is needed, and in the quantities needed. Both Agile and Lean methodologies support this approach. In Lean, work items are pulled only when needed. In other words, a lean engineer starts working on a new Kanban card only when the WIP limit allows the same. 

Similarly, Agile development promotes the JIT approach. It encourages teams to refine, design, and document only the prioritized work items. Moreover, Agile concepts, such as incremental development and emergent design, reinforce this approach.

Waste Elimination

Lean is the major proponent to eliminate waste. Agile methodology, too, supports this concept by delaying decisions until the last responsible moment (LRM). With Agile, any possible rework is minimized.

Differences in Agile and Lean

Some of the core differences between Agile and Lean are as follows:

Origin

Lean management was originated in the manufacturing sector. The original intent was to reduce waste within the Toyota Production System (TPS). Agile methodology, on the contrary, was conceived by the software development thinkers to solve problems with the traditional, plan-based approach.

Nature of work

Lean is best suited for:

  • Managing work that flows through different workflow states
  • Optimizing an existing workflow process
  • Simple and repetitive tasks
  • Eliminating blockers or waste

Agile, on the other hand, is best suited for:

  • Developing complex products
  • Managing work that requires research and experimentation
  • Delivering maximum business value
  • Adapting to frequent changes 
  • Encouraging team collaboration

End Goal

With Lean, the end goal is to deliver work that:

  • Has high-quality.
  • Is released within the shortest sustainable lead time.
  • Is carried out in the most economical way.
  • Has minimal redundancies or waste.

With Agile, the end goal is to deliver a product that:

  • Has the maximum business value.
  • Responds quickly to the changing business needs.
  • Is built incrementally and iteratively.

Team Size

The Lean methodology is applied to improve processes in large enterprises and teams. With Lean, the Value stream mapping helps to visualize end-to-end journeys for large organizations.

On the other hand, Agile is most effective when applied to smaller teams, with a team size of 5-8 people.

Read More

Now that you understand the similarities and differences of Agile and Lean, you can select the methodology that works best for your team. Feel free to add a comment to this post and share your experiences with me. 

Please follow and like us:
error

10 Expert Agile Tips and Techniques

10 Expert Agile Tips and Techniques

This article covers 10 expert Agile tips and techniques for your reference. You can use these valuable insights to create effective, self-organizing teams. These agile tips are in no particular order, so feel free to skim down the list and read the ones that are most suitable for you.

Agile Tip # 1: Discipline

Agile Tips - Discipline

Discipline is the key ingredient in achieving extraordinary results. It brings stability and structure to one’s work or personal life. For instance, it takes discipline to attend scrum ceremonies, meet sprint commitments, and continually learn.

“Discipline is the bridge between goals and accomplishment.” - Jim Rohn

 

Agile Tip # 2: Team Collaboration

Team Collaboration

In Scrum, the entire development team is responsible to ensure that sprint commitments are met. A team member who has completed his assigned tasks should look to assist other team members who need help. In addition, the team should practice empathy towards others, learn new skills, and meets their commitments.

 

Agile Tip # 3: Story Point Estimation

Story Point Estimation

Story points are a relative unit of measure for estimating user stories. A team’s story point estimate should include: 1) the amount of work 2) the complexity of the work 3) any risks or unknowns in doing the work 4) must-have items on your definition of done. 

 

Agile Tip # 4: Splitting User Stories

Splitting User Stories

Split your stories into small stories. In other words, you should resist the temptation to group items together to avoid the management or process overhead. Smaller stories flow better through the sprint. For example, imagine 1,000 marbles working their way down a chute rather than 100 basketballs working their way down the same chute. Therefore, smaller stories are easier to estimate and have less variability than large stories.

 

Agile Tip # 5: Define personas

Agile Tips - Define Personas

Define personas for your product and write persona-based user stories. A persona is a fictional character that you create based on your user research to represent different users that might use your product. In conclusion, understanding the characteristics, experiences, behaviors, and needs of your personas will help you to write valuable user stories.

 

Agile Tip # 6: Maximize the business value

Agile Tips - Maximize Business Value

It is important that you understand the business value associated with each prioritized user story. 

"Your job isn't to build more software faster; it's to maximize the outcome and impact you get from what you choose to build." - Jeff Patton

 

Agile Tip # 7: Focus on One Thing

Focus on One Thing

Are you multitasking or is it context-switching? Research suggests that productivity can be reduced by as much as 40% by the mental blocks created when people switch tasks. Therefore, not only should you work exclusively on what's most important, but you should also look to minimize the number of different things you work on at any given time.

"Extraordinary results are directly determined by how narrow you can make your focus." - Gary Keller

 

Agile Tip # 8: Prioritization

Prioritization

Product owners should consider both importance and urgency when prioritizing product backlog items for the team. In Scaled Agile Framework (SAFe), WSJF or Weighted Shortest Job First technique is used to sequence jobs and ensure maximum economic benefit. Read more here.

"What is important is seldom urgent, and what is urgent is seldom important."- Eisenhower.

 

Agile Tip # 9: Clean Code

Clean Code - Working Software

Write a clean and high-quality code to minimize technical debt.

"Anyone can write a code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Author, and Programmer

 

Agile Tip # 10: Sprint Retrospectives

Sprint Retrospectives

Sprint Retrospectives provide explicit opportunities to improve the existing process. In addition, retrospectives promote ownership and responsibility with respect to all aspects of the process. 

"If you adopt only one Agile practice, let it be retrospective. Everything else will follow." - Woody Zuill

 

Also, read these expert Agile tips and techniques on Medium.

Other useful blogs on Agile:

Do you know how Agile is same or different than the Lean methodology?

What's the difference between Scrum and Kanban?

To learn and practice Agile Scrum, grab my book, The Basics Of Scrum, from Amazon. 

Please follow and like us:
error

What are the 12 Agile Principles?

What are the Agile Principles?

What are Agile Principles?

The Agile Manifesto is comprised of 12 Agile Principles that set the foundation for being agile. Often, people interpret these principles in different ways. In this article, I will break-down each principle into smaller phrases or words to clarify its meaning. Let's dive into each one, understand what they really mean, and be agile. 

12 Agile Principles Explained

Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

12 Agile Principles - Customer First

Agile Principle 1 - Satisfy the Customer                                                                                    Photo by rawpixel on Unsplash

What does this Agile principle mean? The phrase “our highest priority” signifies that the entire product team should know their priorities and should work on the highest priority items first. The highest priority for the product team is to “satisfy the customer” such that the product meets the needs of the customer. The phrase “early and continuous delivery of valuable software” implies that the work completed during the iteration must be demonstrated to the customers as soon as it meets the ‘Definition of Done’ to get their early feedback. Moreover, the team must strive to deliver valuable software to the customers at the end of each time-bound iteration.

 

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

12 Agile Principles - Welcome Changing Requirements

Agile Principle 2 - Welcome Changing Requirements 🙂 Just Kidding!                                         Photo by rawpixel on Unsplash

This Agile principle focuses on embracing change. The phrase “welcome changing requirements” signifies the importance of accepting revised business priorities. The phrase "even late in development" signifies that changes should be welcomed irrespective of the time and effort the team has already invested to develop a feature. It's hard not to get defensive! But, think from your customer's perspective and understand the business value or the key drivers of the change. 

“Intelligence is the ability to adapt to change.” – Stephen Hawking

 

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

12 Agile Principles - Deliver Working Software Frequently

Agile Principle 3 - Deliver Frequently 🙂                                                                                   Photo by Pope Moysuh on Unsplash

Let’s understand what this principle means. The phrase, “deliver working software” means that the Agile development team should target to deliver high-quality production-ready work at the end of each iteration. The team should target to deliver working software frequently, preferably, after every couple of weeks. The shorter the delivery timescale, the more incremental development happens with the lesser cost of change.

 

Principle 4: Business people and developers must work together daily throughout the project.

12 Agile Principles - Collaboration

Agile Principle 4 - Collaboration                                                                                                    Photo by rawpixel on Unsplash

This principle focuses on collaboration between the business and the development team. The phrase “must work together daily” implies that Agile development teams must interact with product sponsors daily throughout the work execution.

“Individual commitment to a group effort – that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi

 

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile Principle 5 - Motivation, Support, and Trust

Agile Principle 5 - Motivation, Support, and Trust                                                                   Photo by Samuel Zeller on Unsplash

What does this principle mean? The phrase, “build around motivated individuals” emphasizes the importance of having motivated people on the team.

“Find people who share your values, and you’ll conquer the world together.” - John Ratzenberger

Give them the environment and support they need” – this phrase means that agile leaders should provide the necessary infrastructure that development teams need to continuously integrate and deploy their changes and should trust the team to deliver valuable software to customers.

 

Principle 6: The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.

Agile Principle 6 - Face-to-Face Conversation

Agile Principle 6 - Face-to-Face Conversation                                                           Photo by Kawtar CHERKAOUI on Unsplash

Out of the 12 Agile principles, this one is based on face-to-face conversation. Face-to-face conversations boost creativity, credibility, trust, and collaboration as people better understand feelings and reactions via body language and expressions. Moreover, face-to-face conversations promote friendliness and build relationships. Therefore, agile leaders, product sponsors, and business stakeholders must meet with the development team in-person regularly.

However, face-to-face conversations are often constrained by the geographical presence of the development team. Platforms for video conferencing provide the same benefits as that of face-to-face conversations and should be encouraged. 

 

Principle 7: Working software is the primary measure of progress.

Agile Principle 7 - Working Software

Agile Principle 7 - Working Software                                                                                       Photo by Markus Spiske on Unsplash

This Agile principle focuses on “working software”. The Agile development team must deliver high-quality work at the end of each iteration that can be released on-demand to end-users or customers of the product. Working software is the primary success measure. Other metrics such as productivity, committed vs actual work, and burndown charts are secondary.

 

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Agile Principle 8 - Constant Pace

Agile Principle 8 - Constant Pace                                                                                           Photo by Boris Stefanik on Unsplash

The phrase “sustainable development” means that work is developed at a constant pace that can be sustained indefinitely without overburdening a development team.

“It does not matter how slowly you go as long as you do not stop.”  – Confucius

 

Principle 9: Continuous attention to technical excellence and good design enhances agility.

Agile Principle 9 - Technical Excellence

Agile Principle 9 - Technical Excellence                                                                     Photo by Kelly Sikkema on Unsplash

This Agile principle states that agile leaders, developers, and the product team must continuously seek technical excellence and emergent design to enhance agility.

“In an agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow.” - Jim Highsmith

 

Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.

Agile Principle 10 - Simplicity

Agile Principle 10 - Simplicity                                                                                                Photo by rawpixel on Unsplash

The developers, product sponsors, and the agile leaders must identify things that do not add value or in other words, must simplify things by maximizing the amount of work not done. 

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is, nothing left to take away.” - Antoine de Saint-Exupery

 

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Agile Principle 11 - Self-Organizing Teams

Agile Principle 11 - Self-Organizing Teams                                                                                Photo by rawpixel on Unsplash

This principle is all about self-organizing teams. The product architecture, design, and features emerge from mature self-organizing teams who can freely take decisions and remove temporary blockers on their own. If developers are free to make decisions, they tend to be more accountable, innovative, and collaborative. Such an environment is best suited for emergent design and iterative development. 

“A self-organizing team has authority over its work and the process it uses.” - Mike Cohn

 

Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Principle 12 - Inspect and Adapt

Agile Principle 12 - Inspect and Adapt                                                                                       Photo by Devin Avery on Unsplash

This principle focuses on inspect and adapt. The phrase “at regular intervals” signifies the importance of setting up a regular cadence to inspect and improve. Agile frameworks recommend regular practices such as product demo and retrospectives to continuously improve the process in an iterative way.

“Continuous improvement is better than delayed perfection.” -  Mark Twain

 

Apply these 12 Agile Principles and be agile. Please post your valuable feedback in the comments section. 

To learn more about the Agile Scrum Framework, read my book, The Basics Of SCRUM. If you like to understand the Lean Kanban method, check out my other book, The Basics Of Kanban.

Please follow and like us:
error

Kanban Boards – Practical Examples

Kanban Boards - Practical Examples

Applying Kanban

What Is a Kanban Board?

A Kanban board is a visual tool for enabling Kanban to manage work for any business. The board helps the team to track each of their work items, minimize idle time, improve predictability, increase quality, and reduce time-to-market.

 

Sample Kanban Boards

Let's dive-in into a few practical examples when teams manage their work via Kanban:

 

Consider a scenario that a DevOps team receives several requests each day to automate build process in Jenkins, resolve test environment issues, onboard new applications onto the hybrid cloud, and so on. Here’s a sample Kanban board for such a scenario.

DevOps Kanban

 

Consider a scenario that an operations team receives several calls during the day from its customers and works together to analyze reported issues, provide real-time guidance, and execute fixes to a customer-facing application. Here’s a sample Kanban board for such a scenario.

 

Consider a scenario that a software development team receives new requests on a regular basis to build new capabilities and enhance existing application features. This team targets to deliver a quality code and invests time in peer code reviews and application testing. Here’s a sample Kanban board for such a scenario.

 

Consider a scenario that an organization’s legal team receives requests on a regular basis from different portfolios in the organization to review content on their sites, campaigns, offers, etc. from a legal point of view. Here’s a sample Kanban board for such a scenario.

 

Consider a scenario that a platform team receives multiple requests from different application teams every day to onboard their applications onto the new platform. Here’s a sample Kanban board for such a team.

 

Consider a scenario that you are buying a new home. In order to track the various tasks and reduce distractions, you create a personal Kanban Board with a WIP limit of 2 home viewings. Here’s a sample Kanban board for such a scenario. 

 

Consider a scenario that you need to sort your house over the weekend. You decide to organize your work and reduce task-switching by creating a personal Kanban board. Here’s a sample Kanban board for such a scenario. 

 

Please follow and like us:
error

Waterfall Vs Agile

Waterfall Vs Agile

Let's analyze the core differences between the plan-driven Waterfall approach and the Agile methodology.

 

Waterfall: Project development flows steadily downwards like a waterfall from one phase to another. The common phases are: Define, Analyze, Design, Build, Test, Launch, and Maintain. The preceding phase must be completed before the next phase can begin.

Agile: Work evolves in an iterative and incremental manner with an emphasis on collaboration, responding to change, and continuous improvement. Its core foundation was laid with the Agile Manifesto for Software Development in 2001. 

 

Waterfall: Encourages conformance to processes and tools

Agile: Values people interactions over processes and tools

 

Waterfall: Requires comprehensive documentation

Agile: Values working software over comprehensive documentation

 

Waterfall: Restricts new ideas

Agile: Encourages experimentation and new ideas

 

Waterfall: Promotes a process-centric environment

Agile: Promotes a people-centric environment

 

Waterfall: Dependent on contract negotiation with customers or suppliers

Agile: Encourages customer collaboration over contract negotiation

 

Waterfall: Requires conformance to a detailed project plan

Agile: Embraces change over following a plan

 

Waterfall: Demotivated team members. Requires a continuous effort to motivate the team.

Agile: Creates high performing, self-organizing, and motivated teams

 

Waterfall: Requires a huge rework to accommodate late changes

Agile: Welcomes changes even late in development with minimal rework

 

Waterfall: High cost of change

Agile: Low cost of change

 

Waterfall: Upfront planning

Agile: Just-in-time planning

 

Waterfall: A higher possibility of mismatch between requirements and the final product

Agile: Frequent feedback loops reduce any mismatch between expectations and results

 

Waterfall: Unhappy customers in spite of the hard work by the development team

Agile: Delighted customers due to frequent feedback and response to changes

 

Waterfall: Requires upfront decisions

Agile: Decisions wait till the last responsible moment (LRM)

 

Waterfall: Does not encourage regular interactions with customers

Agile: Promotes daily collaboration with customers

 

Learn more on Agile, Lean, Scrum, or Kanban with below reads:

Please follow and like us:
error

What is Technical Debt?

What Is Technical Debt?

Learn Agile

Ward Cunningham introduced the concept of technical debt in 1992. He defined it as follows:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

 

Cunningham used the ‘Technical Debt’ metaphor to emphasize the benefits and limitations of speedy development. The metaphor was well received by both business and technical people as it resonates with financial debt. Like financial debt, technical debt accumulates interest with late repayment.
In 2004, Joshua Kerievsky describes ‘design debt’ in his article ‘Refactoring to Patterns” and the associated costs. Then again in 2014, Grady Booch compared evolving cities to evolving software and described how lack of refactoring can lead to technical debt. He stated:

“The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”

 

Get the answers to the below questions in my management book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework, available exclusively at Amazon.

  • What is a Technical Debt?
  • What are the main causes of Technical Debt?
  • What are the consequences of Technical Debt?
  • How do you manage Technical Debt?
  • What are some of the practical examples of Technical Debt?
  • What are some of the practical techniques to manage Technical Debt?
Please follow and like us:
error