Agile Anti-Patterns For Remote Teams

Since COVID-19, agile teams have adopted remote practices to deliver continuous value to their users. Many leaders were unprepared for this remote work culture and thus some agile anti-patterns emerged. In this article, I have listed down some agile anti-patterns for remote teams based on some personal experiences. Before we start, let's understand what an anti-pattern means? An anti-pattern is a pattern that you think will improve things, but it doesn't.

 

Communication and Collaboration

With remote teams, communication plays a critical role. You need a communicate clearly, frequently, and candidly so everyone feels connected. Thus, one of the agile anti-patterns for remote teams that emerged is too many meetings. The break-room conversations near a vending machine or a water cooler have been replaced with meetings. As a result, an engineer does not find enough time during the day to work on his committed stories for the iteration and is spending extra time in the evenings or during weekends to catch up with his or her work.

 

There are multiple ways to deal with this anti-pattern. As agile leaders and scrum masters, we need to:

  • Shield our team from unnecessary meetings and allow them to focus on their committed work.
  • Ensure that teams have access to appropriate collaboration tools such as Slack, Skype for Business, etc.
  • Choose the right collaboration tool to communicate frequently to your team
  • Allow your team to be self-organized

 

Another agile anti-pattern that applies to both co-located and remote teams is conducting meetings with a large number of people even though only 2-3 people are required for the discussion. Other stakeholders simply want to listen to the discussion and track the next steps. To me, this sounds like micro-managing the team rather than trusting them to get the job done. Instead, agile leaders should encourage the team to take ownership, make decisions, have direct conversations, and share outcomes with the larger audience.

 

With a remote setting, there are no quiet corners or conference rooms to catch up on your work. Most managers now expect immediate communication which causes too much disruption, context switching, and lack of productivity. The problem of context-switching is not new, but it has increased with remote teams. Agile leaders should encourage their distributed teams to follow the practice of ‘do not disturb’ hours when they want uninterrupted time to work.

 

The other agile anti-pattern for remote teams is having long meetings that exceed more than 2-4 hours without enough breaks in between. This practice causes both physical and mental stress to the distributed teams. Some of the rituals like lengthy PowerPoint presentations etc. need to stop and meetings should evolve into engaging, interactive, and collaborative sessions that are more inclusive. Moreover, there should be 10-minutes breaks planned for meetings longer than an hour.

 

Not everyone on your distributed teams is trained on Netiquette. When it comes to online meetings, a few guidelines or etiquettes (“netiquettes”) will make them more effective such as:

  • Mute your microphone when you are not speaking
  • Don’t interrupt when the other person is speaking. Only the facilitator has the right to interrupt to keep things on track.
  • Enable your video unless you have a network bandwidth issue at home.
  • Send a meeting invite link to the invitees and details on how to join the meeting.
  • Be receptive to each other's thoughts and remarks

 

Procrastination

Many businesses are struggling during this turbulent time with COVID-19 and have aggressive deadlines to cope up with market instability. With changing business priorities, kids running around the house, increased cooking, household chores, and endless work-at-home hours, remote teams feel more distracted and overwhelmed. They tend to work on multiple tasks at a time. With all this, people start to cherry-pick work that brings them instant gratification while procrastinating on complex long-term solutions. During this time, agile leaders should constantly encourage teams to stay calm, manage stress, take regular breaks, minimize context switching, and focus on business outcomes.

 

Facilitation

Remote teams are re-inventing effective ways to facilitate their ceremonies such as daily scrum, retrospectives, sprint planning, sprint review, virtual PI planning, and other SAFe, Scrum, or Kanban ceremonies. Let’s discuss a few agile anti-patterns in this area.

 

One of the agile anti-patterns is being the lone facilitator for a virtual meeting with a large number of participants. With more than 30 people in a meeting, it becomes challenging for the facilitator to share screen, take notes, capture risks, write down parking lot items, etc. while keeping conversations on-track to achieve the goal of the meeting. Thus, it is recommended to designate a scribe or a co-facilitator during such events.

 

Another anti-pattern is using flip charts or physical whiteboards (with a video camera pointed towards them) in a virtual meeting. This arrangement doesn’t work well and frustrates people as they struggle to read the content. Instead, facilitators should research the appropriate virtual drawing board or applications that promote visual collaboration within the team such as Mural, Miro, Draft.io, etc.

 

A common anti-pattern when teams first start with virtual events such as PI Planning is lack of preparation before the event. For a virtual event to be successful and meaningful, teams must invest time in preparatory work. A Scrum Master should work with the Product Owner to carve out the team’s capacity for the preparatory work.

 

Remote teams should watch out for a common agile anti-pattern when daily stand-ups become a status meeting. With no eye contact amongst the remote members, the team tends to report status to the scrum master. Another agile anti-pattern of skipping retrospectives holds good for remote teams too. With multiple meetings, increased stress, and more work, teams tend to defer or skip inspect and adapt ceremonies, don’t have enough backlog refinement meetings, start delivering work that has not met the “Definition Of Done”, and more. These common anti-patterns will impact an agile team’s ability to deliver business value and to continuously improve.

 

Built-In Quality and Technical Debt

Due to aggressive deadlines, increased stress, and reshuffled business priorities during this pandemic, it is quite likely for remote teams to de-prioritize technical debt reduction efforts such as code clean-up, automated testing, etc. This will result in the accumulation of technical debt over time. A few more agile anti-patterns that remote teams should watch out for are listed below:

  • Missing Acceptance Criteria
  • Undefined Definition of Done
  • Delivering work without meeting the `Definition of Done`
  • Lack of appropriate testing
  • Lack of required documentation

 

These are a few remote agile anti-patterns that I have experienced. If you agree or disagree or if you would like to share your experiences, let me know in the comments section.

 

Check out my published books on Agile and Lean:

 

You may also be interested in these articles...

Virtual PI Planning

Virtual PI Planning

Amidst the increasing number of confirmed Coronavirus cases, several organizations are mandating their colleagues to work from home. In such times, Release Train Engineers (RTEs) and Scrum Masters (SM) are searching for creative ways to execute virtual PI planning. This article provides valuable insights into conducting the event effectively. With this post, you will also understand different options available readily to you for creating an online Program Board. Below is the list of activities that an RTE must consider when conducting a virtual PI planning.

 

 

  • Primary WebEx details should be shared with everyone prior to the event. This WebEx room must be open during the entire event and will act as the common forum to ask questions and collaborate across teams as needed.

 

  • WebEx details for additional/secondary rooms should also be published prior to the event. These WebEx rooms are required to facilitate team breakouts. There should be a separate WebEx room for each team.

 

  • Ensure that the primary and secondary WebEx rooms are different.

 

  • If you are sharing your screen during a WebEx meeting, it is often challenging to take notes. Thus, I recommend that you designate scribes for managing parking lot items, capturing risks or dependencies, etc.

 

  • Pre-PI planning Preparation: The more the preparation prior to the PI planning event, the better or smoother the virtual event will go. Here are a few things to remember:

 

    • Ensure that prioritized product features are created and refined at least 3 weeks prior to PI planning.

 

    • Bring team break-outs forward. During the breakout sessions, teams estimate their capacity for each iteration, identify risks and dependencies, refine user stories, and create their draft plan for each iteration. All these activities can be planned prior to the PI planning event. As a result, during PI planning, the time needed for team breakouts will be reduced.

Please Note: For the pre-PI planning preparation to be successful, Scrum Masters must plan team capacity for these activities.

 

  • Next is to set-up a virtual Program Board. Based on my research, there are multiple options available to you:

 

    • Use Miro: You can use the free version without any issues. However, if this is not an approved product within your organization, you may not be able to leverage this product. I recommend that you consult with your leaders before going ahead with this option.

 

    • Check out other similar products available in the market. For Example: Mural, piplanning app, etc.

 

    • If you use Rally, JIRA, or any other agile management tool to track features/user stories, you may explore if there’s a custom board/view available within the tool itself. This will minimize your post-PI planning effort to manually migrate team dependencies, risks, and milestones into the tool.

 

    • Use Confluence. You can build a custom view using the Gliffy Diagram and build the Program Board on Confluence. You can also share the confluence link ahead of time so teams can leverage the same during team breakouts.

 

Check out my published books on Agile and Lean:

 

You may also be interested in these articles...

 

Leadership Agility: What You Need to Know

What is Leadership Agility?

In today's complex, turbulent, and competitive business and technology environment, leaders need to master the skills required to become more proactive, collaborative, creative, and agile. Leadership agility is the core competency of agile leaders to make effective decisions, inspire others, bring others along, build the best team, be proactive, develop a culture of teamwork, define objectives, and contribute to strategic initiatives for the enterprise.

 

"Agility is fundamental to leading a team through times of change." - Sandra E. Peterson

 

What drives Leadership Agility?

Leaders' agility is the core reason behind the success of any enterprise or business. Some of the common drivers of leadership agility are listed as below:

 

Being a change agent

With this fast-paced environment, leaders need to accept that change is inevitable, and be prepared to embrace change. For an organizational change to be effective, leaders should initiate and respond to change quickly. If people believe in your decision-making skills, they will trust your ability to drive the change. 

 

Employees need leaders who are committed to their success, seek feedback, make tough decisions, and communicate openly. Leaders who show personal commitment to change and inspire others to accept change play a critical role as change agents for the organization.

 

"If you are not willing to risk the unusual, you will have to settle for the ordinary." - Jim Rohn

 

Setting a vision and inspiring others

Leaders have a vision that inspires and brings people together. Leaders understand the importance of setting a shared purpose for their teams. Their vision is manifested in their actions and their goals. 

 

"Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion." - Jack Welch

 

Leaders should strongly believe in their vision. The vision should reflect organizational purpose, motivate colleagues, display the organization's values, and explain the WHYs.

 

Creating a culture of openness, collaboration, and trust

Every agile leader must foster an open environment of trust and collaboration where people can freely discuss their ideas, experiment with their designs, collaborate, have the freedom to make mistakes, and have fun together. 

 

"You need to be aware of what others are doing, applaud their efforts, acknowledge their successes, and encourage them in their pursuits. When we all help one another, everybody wins." - Jim Stovall

 

Decentralizing decisions where possible

Decentralized decisions reduce unnecessary delays and improve the flow of work. Agile leaders must understand when and which decisions they must decentralize. Frequent or time-critical decisions that need local context should be decentralized. Other decisions that are long-lasting and have a huge impact should remain centralized. Decentralized decisions empower the team to make decisions.

 

Embracing Lean-Agile Principles

Successful leaders embrace lean thinking and lean principles outlined by the House of Lean such as Kaizen (continuous improvement), respect for people, teamwork, innovation, sustainable flow, and Genchi Genbutsu (go and see). Lean thinking encourages leaders to embrace core values such as respect, integrity, empathy, collaboration, and teamwork. 

 

“Success today requires the agility and drive to constantly rethink, reinvigorate, react, and reinvent." - Bill Gates

 

Agile leaders embrace the values written in the Agile Manifesto and promote the 12 Agile principles across their teams. If you are interested to read about 12 Agile Principles, check out this article on Medium.

 

Check out my published books on Agile and Lean:

 

You may also be interested in these articles...

 

Do You Measure Kanban Throughput?

What is Kanban throughput? What's the best way to measure it? This article reflects on these questions and provides a perspective to track a Kanban team's performance in an effective way.

 

What Is Kanban Throughput? 

Kanban Throughput is defined as the average number of items or cards passing through the flow within a specific time duration provided that the work load stays uniform during that period. It is generally used to track team's performance. Throughput variability reflects the difference in size, complexity, and team skills.

 

According to the Little's Law:

Throughput = Total WIP / Average Lead Time

 

Measuring What Matters: Kanban Throughput

The best way to measure throughput in Kanban is with the CFD (Commulative Flow Diagram). The Cumulative Flow Diagram is the visual representation of the cards as they move from one column or state to another on a Kanban board. The CFD plots the number of cards at each stage at a given time.

 

Below is a sample CFD for your reference:

 

Sample CFD Diagram

 

The different colors on this diagram represent the various states in the flow. The height of each color band indicates the number of cards in that state at that point in time. 

 

The CFD provides you with an insight on how many cards moved from one state to another in a specific time duration. Generally, the CFD is plotted for each day, however, if there are too many moving cards in a day, it can be plotted on an hourly basis as well. Below is a sample CFD when plotted for every hour in a working day.

 

Sample CFD - Plotted Hourly

 

Moreover, the CFD provides valuable data on lead time and cycle time trends. Both lead time and cycle time denote the time a work item spends in the workflow until they are complete. Lead time is the time that a card takes from start to finish. Cycle time is the time an engineer spends to actively work on it. In a CFD, both lead time and cycle time metrics are measured along the horizontal axis.

 

The Cumulative Flow Diagram (CFD) also displays total cards across different columns i.e. total WIP. This data is measured along the vertical axis of the CFD diagram.

 

Below is a sample CFD that depicts lead time, average cycle time, and the total WIP.

 

Sample CFD Diagram With Lead Time, Cycle Time, and Total WIP

 

If you are interested about other Kanban charts such as Average Lead Time, Average Cycle Time, Flow Efficiency Chart, or the Blocker Clustering Chart, read my book, The Basics Of Kanban - A Popular Lean Framework.

 

You may also be interested in these articles...

...and below books on Agile and Lean:

Will OKRs Rule The World?

Will OKRs rule the world? This article captures my thoughts on OKRs and their impact on the corporate industry.

 

What are OKRs?

OKR stands for Objectives and Key Results. It is a simple management methodology and an agile goal-setting system that enables everyone to align with enterprise objectives and to visualize the progress made towards them.

 

Founded by Intel CEO, Andy Grove, in the 1970s, the OKRs methodology was first adopted by Google in 1999. Since then, OKRs have helped Google and several other enterprises to stay focused, create transparency, gain alignment, and achieve better results. Today, several organizations across all sectors such as Spotify, LinkedIn, Walmart, Bill and Melinda Gates Foundation, and others are using this framework to set and achieve audacious goals.

 

In 1999, John Doerr, a venture capitalist, introduced OKRs to Google. In his meeting with Larry Page and Sergey Brin, co-founders of Google, he introduced the OKR system and explained how it can help Google to achieve its aggressive growth targets. In his book, Measure What Matters, John revealed how the system of OKRs has helped organizations achieve agility and explosive growth.

 

John Doerr’s formula for OKRs is:

I will (Objective) as measured by (set of Key Results).

 

Objectives define 'what' is to be achieved. They are qualitative, significant, concrete, short, inspirational, memorable, and ambitious. Each objective could have 2-5 key results.

 

Key Results define 'how' we achieve the objectives. They are a set of measurable milestones for each objective to track progress towards achieving the objective. They are quantitative, specific, measurable, time-bound, verifiable, and aggressive, but realistic. When key results are complete, the objective is necessarily achieved.

 

Will OKRs Rule the World?

Let’s look at some of the common problems faced these days and if OKRs can prove to be beneficial in those scenarios.

 

One of the common problems today is conflicting priorities. Often, different stakeholders have conflicting views on the features or capabilities that a product roadmap should include. Such conflicts lead to unpleasant conversations, strained relationships, and a demotivated team.

 

The OKRs framework brings focus to the purpose or objectives that a product has. The stakeholders start to think in terms of the product vision and its goals that they are trying to achieve. With OKRs, there’s also a better clarity on the success metrics or the key milestones for each product objective.

 

“OKRs are clear vessels for leaders’ priorities and insights.” -  John Doerr

 

The other common problem these days is lack of measurement or tracking of the specific outcomes or product goals. Teams continue to build new features and capabilities for the product but seldom measure the outcome or the result.

 

With the OKR model, Key Results (KRs) are measured and tracked periodically.

 

“If the focus is delivering something the customer wants, you must move from primarily measuring outputs to primarily measuring outcomes.” - Mario E. Moreira

 

But does one size fits all? No, OKRs are not meant for all enterprises. OKRs will not work for you when:

 

  • OKRs are not agile: When OKRs are rigid, the model does not provide any room for people to make mistakes, abandon OKRs, or be agile. The OKR model is meant to inspire people and drive better alignment, focus, engagement, and performance.

 

  • OKRs don’t flow quickly down the corporate hierarchy: Some enterprises find it difficult to align corporate OKRs with portfolio and team OKRs. Thus, it takes a considerable amount of time for them to cascade strategic OKRs to the teams.

 

  • When conflicting priorities are tough to resolve: With conflicting priorities, planning becomes a nightmare and it might consume a considerable amount of time and effort to lock down OKRs for each quarter.

 

If you would like to read more on OKRs and Enterprise Agility, you might like my latest book, Enterprise Agility with OKRs.

 

Download the FREE Agile templates for strategic planning:

  • The Product Persona Template
  • The Product Vision Template
  • The Product Roadmap Template

You may also be interested in these articles...

...and below books on Agile and Lean:

The Future Of Agile

The Future Of Agile

What's the future of Agile? This article will discuss the current and future trends for the Agile methodology.

 

Where Are We Today?

Agile was formulated in 2001 with a Manifesto for Agile Software Development. Since then, several enterprises across the world have adopted the agile methodology. Most organizations build complex products using Agile frameworks such as Scrum, Extreme Programming, Feature-Driven Development (FDD)Dynamic Systems Development Method (DSDM), or Crystal. Several organizations leverage the Lean methodology alongside the Agile methodology and track their work using the popular Kanban method. Since these frameworks didn't address the specific problems faced by large organizations, many organizations also adopted scaled Agile frameworks such as Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined Agile Delivery (DaD).

 

With increased Agile maturity, teams adopted DevOps practices such as Continuous Integration (CI), Automated Builds, and Continuous Deployment (CD), as well as practices as Behaviour-Driven Development (BDD), Test Driven Development (TDD), Acceptance Test Driven Development (ATDD), Automated Unit Tests, and so on...

 

What's The Future Of Agile?

The next big thing in Agile is the Purpose-Driven Development (PDD). There is a clear need to understand enterprise's objectives or purpose, program objectives, and product goals before starting development on any product feature. The product goals, when mapped to primary personas and to enterprise OKRs, bring the maximum benefit. Not only do they drive the product roadmap, they also bring alignment across product stakeholders. 

 

Thus, the future is to bring strategic planning to the product. Leaders should invest time in understanding their customers or users, their problems, and how the product can benefit them. The personas, together with enterprise objectives, should drive the product's purpose or goals, which in turn, should drive the product's roadmap.

 

If product goals no longer align to enterprise objectives or the persona's needs, then the enterprise should have the agility to quickly adapt to the change, move funds or people, and re-plan priorities.

 

Download the FREE Agile templates for strategic planning:

  • The Product Persona Template
  • The Product Vision Template
  • The Product Roadmap Template

 

You may also be interested in these articles...

 

...and below books on Agile and Lean:

Enterprise Agility – Expectations Vs Reality

What is Enterprise Agility? What are the expectations vs the reality of Enterprise Agility (EA)? This article covers the six pillars of EA that sums up the expectations or the future state along with the actual state of things.

"The rate of change is not going to slow down anytime soon. If anything, competition in most industries will probably speed up even more in the next few decades." - John P. Kotter

 

Enterprise Agility - Expectations

Enterprise Agility is centered on the ability of an enterprise to quickly respond to change. Agile enterprises are expected to have:

  • Planning Agility
  • Funding Agility
  • Team Agility
  • Technical Agility
  • Leadership Agility
  • HR Agility

 

Planning Agility

The planning agility represents the flexibility of an enterprise to change its priorities considering changing market conditions or emerging technology trends. The expectation is that an enterprise is able to reprioritize and realign its business priorities quickly with changing market conditions or customers' preferences.

 

Funding Agility

This is closely related to the planning agility. In order to quickly adapt to changing market conditions or emerging technologies, an enterprise must have the flexibility to move its funds or resources around, across teams, departments, and products, depending on the need.

 

Team Agility

Enterprise agility can only be achieved when all teams across an enterprise have adopted the agile mindset, values, and principles. For a team to be agile, they must adapt to change, learn to collaborate, self-organize their work, and consistently deliver high-quality work to generate business value.

 

Technical Agility

Teams achieve technical agility by leveraging engineering practices to deliver high-quality products quickly. Some of these practices include continuous focus to architecture and quality design, test-driven development (TDD), behavior-driven development (BDD), continuous integration (CI), continuous deployment (CD), creating unit tests, and ensuring code quality.

 

Leadership Agility

This is an important competency for enterprise executives and leaders to develop. Leadership agility is the ability to make effective decisions, inspire people, and act with an understanding of what it takes to lead in a rapidly-changing world. With more agility, leaders become more collaborative and proactive in leading teams and driving organizational changes.

 

HR Agility

In an agile enterprise, it is important to integrate HR and other supporting departments such as Finance, Sales, Marketing, etc. with the product development process and introduce agility into their work.

 

Enterprise Agility - The Reality

But, are enterprises “truly agile”? Are you able to quickly adapt to the changing market conditions or emerging technology trends? When your corporate strategy/goals shift, how soon will the change flow from the corporate level to your own products? How soon will funds move from one product to another or from one release train to another?

Let's take a step back and think - does your roadmap even align with your corporate goals? How often do you revisit your product roadmap?

The reality is that change is slow. Larger the organization, more difficult it is to be agile. If the enterprise has adopted Scrum or Kanban, or SAFe, it doesn’t mean that they can quickly adapt to change. With SAFe, the product priorities are revisited on PI boundaries, thus it could take around 10-12 weeks to realign priorities. It may take even more time to move funds and resources between different departments. Enterprises often compromise their agility to have the desired predictability.

 

Post your comments on the expectations vs the reality of Enterprise Agility. Also, check out my latest book, Enterprise Agility with OKRs.

 

More articles:

 

More Books by Aditi Agarwal on Agile and Lean:

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:

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.

 

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

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

 

Agile Principle 11 - Self-Organizing Teams

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

 

Agile Principle 12 - Inspect and Adapt

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.