Scrum Vs Kanban

Scrum Vs Kanban

Scrum in a nutshell

Scrum is an iterative or incremental 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. Each iteration begins when the team aligns on a subset of the highest priority items that it can complete in that iteration. Each iteration ends when the team has delivered a potentially shippable product increment of the product. The team delivers value to the customer at the end of each iteration or a time-boxed cycle.

There are three defined roles – Product Owner, Scrum Master, and the Development Team. 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 regularly:

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

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 bestselling book, The Basics Of Scrum – A Simple Handbook to the Most Popular Agile Scrum Framework. 

Kanban in a nutshell

Kanban works best for teams that have a continuous flow of incoming requests with different priorities. In Kanban, each request or work item is represented by a Kanban card that flows from one stage of the workflow to another until it’s 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 Kanban, there is a significant focus on improving time to market and eliminating waste.

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

 

Let's analyze the core differences between Scrum and Kanban.

Scrum: Formed for complex product development to mitigate the limitations with the Waterfall method

Kanban: Originated to manage work and control inventory at Toyota with just-in-time and lean principles

 

Scrum: Time-boxed and fixed length sprints

Kanban: Continuous flow

 

Scrum: Can release at the end of every sprint or on-demand

Kanban: Continuous delivery or at the team's discretion

 

Scrum: Required roles - Product Owner, Scrum Master, Development Team

Kanban: No specific roles required

 

Scrum: The smallest piece of business value that a team delivers is a User Story.

Kanban: Each work item is represented as a Kanban card.

 

Scrum: Best suited for complex and unpredictable efforts

Kanban: Best suited for both simple and complicated efforts where things are more predictable than they are unpredictable

 

Scrum: Sprint Retrospective is conducted at the end of every sprint to inspect and adapt the existing process.

Kanban: Service Delivery Review is conducted on a monthly or quarterly basis to review cycle time, flow efficiency, etc.

 

Scrum: Requires user stories to be estimated in terms of story points.

Kanban: Does not require items or cards to be estimated. In Kanban, estimation is optional. Some teams choose to estimate their cards to have more predictability while others prefer to split their stories such that each of the cards is of the same size.

 

Scrum: Sprint Burndown and Velocity are the key charts.

Kanban: Cycle time and Throughput are the key metrics.

 

Scrum: Less flexible

Kanban: More flexible

 

Scrum:  Ceremonies are conducted on a regular cadence.

Kanban: Meetings are held as needed.

 

Scrum: Additional stories should not be added to the active/ongoing sprint. 

Kanban: Additional work items can be added anytime, assuming it’s within WIP limits.

 

Scrum: A Scrum board or the sprint backlog is reset after every sprint.

Kanban: A Kanban board is continuously used.

 

Scrum: Requires a bigger shift with roles, ceremonies, estimations, and iterations.

Kanban: Nothing needs to change significantly to get started with Kanban.

 

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:

Agile and Lean

Agile and Lean

Agile and Lean

People often debate whether Agile and Lean are the same or different. Sometimes, people ask me which one is the best methodology for their business. This article presents some similarities and differences between the two methodologies.

Similarities in Agile and Lean 

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

Development approach

Lean development encourages to reduce the batch size and limit work-in-progress (WIP). Agile methodology, too, promotes prioritization of work items and incremental development of working software within short, time-boxed iterations.

Continuous Improvement

Lean development is very focused on Kaizen or continuous improvement. Agile development also signifies the importance of the 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 development, too, has a strong focus on people interactions and collaboration with product stakeholders. The below two values stated in the Agile Manifesto reflect the same.

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

Moreover, the 4th Agile principle, ‘Business people and developers must work together daily throughout the project.’ is also focused on collaboration.

Customer-centric approach

Lean is a customer-centric methodology that focuses to deliver the best quality and value in shortest sustainable lead time. Agile methodology is customer-centric as well. 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 approach

Both Agile and Lean methodologies encourage the Just-in-Time approach. One of the two pillars in the Toyota House of Lean is ‘Just-in-Time’ that encourages to produce only what is needed when it is needed, and in the quantities needed. Agile development, too, promotes ‘Just-in-Time’ planning, design, development, and documentation. Agile encourages teams to refine, design, and document only the prioritized work items. Agile concepts such as incremental development and emergent design reinforce the ‘Just-in-Time’ approach.

Waste Elimination

Though Lean is the major proponent for waste elimination, Agile methodology, too, supports this concept by delaying decisions until the last responsible moment (LRM). Thus, with LRM, possible rework, caused when working on an incorrect feature or an incorrect design, is minimized.

Differences in Agile and Lean

Let’s look at some of the core differences between Agile and Lean.

Origin

Lean management was originated in the manufacturing sector with the intention to reduce waste and improve the efficiency of the existing system, whereas Agile methodology was conceived by the software development thinkers to solve problems with the traditional software development approach.

Nature of work

Lean methodology is best suited to optimize simple, repetitive tasks that flow through different workflow states. On the contrary, Agile is best suited to build complex products that require research, experimentation, ability to adapt to change, and collaboration.

End Goal

With Lean, the end goal is to deliver a high-quality product in shortest sustainable lead time in the most economical way while eliminating redundancies and waste. With Agile, the end goal is to deliver the maximum business value, respond quickly to the changing business needs, and develop incrementally in an iterative way.

Team Size

Lean methodology is applied to improve processes in large enterprises and teams. Value stream mapping helps to visualize the end-to-end journey or steps required to deliver value to the customer. On the other hand, Agile is most effective when applied to small teams with a team size of 5-8 people.

Learn more on Agile and Lean with my short book, The Basics Of Agile and Lean

Please follow and like us:

10 Expert Agile Tips and Techniques

10 Expert Agile Tips and Techniques

This article covers the expert agile tips and techniques for your reference. You can use these valuable insights to create effective, self-organizing teams. These 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. 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

Agile Tips - 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. The team should practice empathy towards others, learn new skills, and meets their commitments.

 

Agile Tip # 3: Story Point Estimation

Agile Tips - 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

Agile Tips - Splitting User Stories

Split your stories into small stories. Resist the temptation to group items together to avoid the management overhead. Smaller stories flow better through the sprint. Imagine 1,000 marbles working their way down a chute rather than 100 basketballs working their way down the same chute. Smaller stories are easy 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. 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

Agile Tips - 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. 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

Agile Tips - 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

Agile Principle 7 - 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

Agile Tips - Sprint Retrospective

Sprint Retrospectives provide explicit opportunities to improve the existing process. 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 my agile tips on Medium.

 

Continue reading

Please follow and like us:

What are the Agile Principles?

What are the Agile Principles?

What are Agile Principles?

Let's understand the 12 Agile Principles that set the foundation for being agile. The following principles are based on 'The Agile Manifesto'.

 

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

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.

Agile Principle 2 - 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.

Agile Principle 3 - 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.

Agile Principle 4 - 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

This principle is all about face-to-face conversation. Agile leaders, product sponsors, and business stakeholders must meet with the development team in-person regularly. Face-to-face conversations boost creativity, credibility, trust, and collaboration as people better understand feelings and reactions via body language and expressions. Face-to-face conversations also promote friendliness and build relationships. Often, face-to-face conversations are 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 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

The 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 to be agile. Hope this article provided value to you. Please post your valuable feedback in the comments section. Thank you!

To learn more about the Agile Scrum Framework, read my bestselling 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:

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:

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: