Home » Blog » Agile and Lean » Page 2

Agile and Lean

Posted on March 30, 2019October 20, 2019 by Aditi Agarwal

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.

More articles:

Learn more on Agile, Lean, Scrum, Kanban, and Enterprise Agility with below books:

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.

10 Expert Agile Tips and Techniques

Posted on February 9, 2019October 31, 2019 by Aditi Agarwal

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

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

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

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

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

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

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

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

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

What are the 12 Agile Principles?

Posted on February 9, 2019November 23, 2019 by Aditi Agarwal

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.

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.

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

What is a Sprint Burndown Chart?

Posted on April 13, 2018October 20, 2019 by Aditi Agarwal

The Sprint Burndown or the Iteration Burndown chart is a powerful tool to communicate daily progress to the stakeholders. It tracks the completion of work for a given sprint or an iteration. The horizontal axis represents the days within a Sprint. The vertical axis represents the hours remaining to complete the committed work. The purpose of a sprint burndown chart is to show the total amount of work remaining.

Let's take an example. The below table shows the actual number of hours remaining at the end of each day within a Sprint to create a sample Sprint burndown chart. The table also captures data for ideal remaining hours. The ideal remaining effort is calculated by assuming a uniform rate of task completion each day. In the below example, you can see that the ideal and actual remaining hours were same at the beginning of the sprint, however, as the sprint progresses, the actual remaining hours vary from the ideal remaining hours.

Next, we will plot a sample Sprint Burndown chart using the above table data. The below diagram depicts the sample chart with ‘Date’ represented on the horizontal axis and ‘Remaining Effort (Hours)’ represented on the vertical axis.

From the above chart, you can conclude that:

There were no spillover stories since the actual remaining hours at the end of the sprint were zero.
The team started a bit slow in the first week of the sprint, but then caught-up during the second week.

Learn all about Agile Scrum with my book, The Basics Of SCRUM. Other Books:

Waterfall Vs Agile

Posted on February 15, 2018October 19, 2019 by Aditi Agarwal

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

In Waterfall methodology, 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 and signed-off before the next phase can begin. In Agile methodology, 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.

The Waterfall methodology encourages conformance to plan and processes, however, the Agile methodology values people interactions more.

Waterfall is the plan-driven or the traditional project management approach that requires comprehensive documentation, whereas, the agile methodology focuses on working software over comprehensive documentation.

The plan-driven or the Waterfall approach restricts new ideas that arise during design, build, or test phases of the project, whereas the agile methodology encourages experimentation and new ideas at all times.

Waterfall promotes a process-centric environment, whereas Agile promotes a people-centric environment.

With Waterfall methodology, projects are dependent on contract negotiation with customers or suppliers, however, Agile encourages customer collaboration more than contracts.

The traditional Waterfall methodology requires conformance to a detailed project plan, whereas, the Agile methodology embraces change. The change control process in the Watefall methodoly is a very time-consuming process that requires a detailed impact analysis, a feasibility study, and possible re-distribution of resources/funds. With Agile, desired changes can simply be written as new user-stories/work items and can be added to the product backlog at any time.

Waterfall requires a continuous effort to motivate the team. Most often, team members are not interested in the outcome of the project. On the contrary, Agile focuses on creating high performing, self-organizing, and motivated teams. In an Agile environment, team members understand the objectives and iteration goals and feel connected to the greater purpose.

The Waterfall approach requires huge rework to accommodate late changes during design, build, test, or rollout phases of the project. As a result, the cost of change in this approach is quite high. On the other hand, Agile welcomes change even late in development with minimal rework, keeping the cost of change low.

When Waterfall is synonymous with upfront planning, Agile is all about Just-In-Time (JIT) planning.

With the Waterfall methodology, there's a high possibility of mismatch between approved requirements and the released product, whereas, Agile encourages frequent feedback loops that reduce any mismatch between expectations and results.

Often, with the Waterfall approach, customers stay unhappy in spite of the effort put in by the development team. Agile methodology is customer-focused. Customers stay delighted due to frequent feedback and quick response to changes or team agility.

Waterfall requires upfront decisions and approvals for the requirements document, the design documents, test strategy, etc. In Agile, decisions wait until the last responsible moment (LRM). LRM is a strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.

In the Waterfall approach, there is a limited interaction between the developers and customers (especially once the design phase starts). On the contrary, Agile promotes frequent collaboration with customers with daily stand-ups, backlog refinement, iteration planning, and product demo, and retrospective ceremonies for each iteration or sprint.

How to manage estimate inflation?

Posted on December 2, 2017October 9, 2019 by Aditi Agarwal

What is estimate inflation?

Estimate inflation is the term used when team estimates start growing over time. If a product backlog item was earlier estimated as 3 story points and a similar item is now estimated as 5 story points, this is referred to as estimate inflation.

What causes estimate inflation?

Higher management, often, mistakes high velocity as high productivity and put a tremendous pressure on the scrum teams to increase their velocity. In order to achieve a target velocity, the team then starts inflating their story point estimates. This inflation has a ripple effect on other product backlog items that have not yet been estimated. During planning poker, when team estimates a product backlog item, they compare their story to an already inflated story and provide another inflated estimate.

How to limit estimate inflation?

Mike Cohn recommends comparing the product backlog item being estimated to two or more other items to ensure consistency among estimates. When you compare the item with two or more backlog items during planning poker, the probability to compare against inflated estimates is reduced.

What are the challenges to this approach?

Time is the biggest challenge. The development team does not like to spend additional time during planning poker to compare the item against multiple backlog items.

What is Technical Debt?

Posted on October 14, 2017October 31, 2019 by Aditi Agarwal

If you are applying the Agile Scrum Framework at work, you must have heard the term, Technical Debt. So, what is the Technical Debt? Who invented this term? In this article, you will understand what it means and how to manage it.

The Definition

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 the financial debt. Like the financial debt, this 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 the technical debt. He stated:

“The concept of the 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.”

Main Causes of the Technical Debt:

Review your product, system, code, practices, and processes for:

Outdated design
Low code coverage
Lack of automated regression test suite
Lack of continuous integration
Lack of appropriate testing
Tightly-coupled code
Delayed code refactoring
Aggressive timelines

How to manage the Technical Debt:

An organization should enforce good technical practices to all the developers, including but not limited to technical design review, code review, automated regression suite, high code coverage, adequate testing, and continuous integration. This will limit the accrual of this debt. The products that have accumulated the debt should focus on refactoring to reduce technical debt and improve maintainability. Below techniques will reduce your debt:

Have a strong definition of done
Create visibility for the tech debt
Prioritize the tech debt
Leverage an incremental approach

Learn more about the technical debt and other concepts of the Agile Scrum Framework with my book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework, available on Amazon.