Category Archives: Agile and Lean

This page contains my posts on Agile and Lean methodologies. Develop an agile mindset and have lean thinking to be a lean-agile leader. Below are the posts for this category:

Agile Metrics: Output Vs Outcome

Posted on by

Before we dive into Output Vs Outcome-Based Agile Metrics, let us understand what is meant by output-based and outcome-based metrics. Output-Based metrics measure the amount of work completed whereas Outcome-Based metrics measure the value delivered by the completed work.

Output-Based Agile Metrics

Metrics that measure how much work was completed in a given duration are said to be output-based. For example, the number of user stories completed in a Program Increment (PI) or an iteration measures the number of tickets completed in a specified duration. Other examples are:

  • Number of features completed in a Program Increment
  • Number of story points completed in a Program Increment
  • Number of story points completed in a sprint or an iteration

Such metrics can be easily gamed and do not provide any value-add. For example, Team A delivers 6 user stories whereas Team B delivers 12 user stories. This metric does not signify that Team B has better productivity than Team A.

Let’s assume Team A delivers 40 story points and Team B delivers 20 story points. Do you think Team A is a better performing team than Team B? Well, a team’s velocity does not provide insight into a team’s performance. Team A might have inflated their story point estimates or they might be working on user stories that do not deliver a potentially shippable product increment or bring any business value. 

Measuring the amount of work done is an Agile anti-pattern and should be avoided. It does not provide any value and may encourage Agile anti-patterns such that teams write tasks as user stories, create unnecessary user stories that do not bring any business value, and inflate story point estimates.

Outcome-Based Agile Metrics

Metrics that measure the outcome or the end-value delivered by the completed work are said to be outcome-based. For example, the business value delivered is an outcome-based metric that measures the amount of business value delivered by a unit of work during a specific duration. Let’s discuss how to measure the business value for an EPIC, Feature, or User Story. 

How to Measure the Business Value

Measure the delivered business value at an EPIC or a Feature level, rather than at a User Story level. Think in terms of:

  • Will this EPIC or Feature enable you to sell more units?
  • Will this EPIC or Feature allow you or your organization to make more profit?
  • Will this EPIC or Feature enable reduced operating costs for your business?
  • Will this EPIC or Feature enable a new capability for your end-users?
  • Will this EPIC or Feature reduce the manual effort for your team or end-users?
  • Does this EPIC or Feature enable your organization to compete in the market?
  • Does this EPIC or Feature allow to refine hypotheses about the market? 
  • Is this EPIC or Feature required to stay compliant with regulations?

Many EPICs or Features provide little to no value or aren’t actually desired by end-users. It’s important to prioritize the work effectively to deliver more business value. There are many ways to measure the business value like comparing the cost of delay, calculating Return On Investment (ROI), calculating revenues and expenses each month (Cash-Flow analysis), calculating Net Present Value (NPV), Planning Poker, and more. I suggest working with your business sponsors and:

  • Find Key Value Indicators (KVIs) for your product that you can measure at each Product Increment (PI) boundary.
  • Think about both qualitative and quantitative value indicators.
  • Review your KVIs regularly and revise as needed.

One of the simpler methods is to leverage the Planning Poker game and relatively estimate the business value for an EPIC or a Feature with your product stakeholders.

If you are interested to learn about other Outcome-Based Agile Metrics, enroll in my Udemy Course, Agile Metrics: Elevate Team Agility with Scrum Reporting.

You may be interested in my published courses and books as outlined below: 

Also, check out these articles…

Customer Journey Map Template

Posted on by

Customer Journey Map

In this article, let me introduce you to the Customer Journey Map template I have designed. This template will simplify the data gathering and visualization of required data attributes such as your persona's needs or motivations, important events, touchpoints, and actions. But first, let's start with the definition.

What is Customer Journey Mapping?

Customer journey mapping is the process of creating a customer journey map, which is a visual representation of your customer’s or prospect’s interactions with your product. This strategic exercise helps to think from customers’ or prospects’ perspectives and better understand their expectations, pain points, motivations, and needs. The journey map maps out all touchpoints from the first to the final touchpoint for both your existing and potential customers and is leveraged to visualize and improve the overall customer onboarding and experience.

How to create a Customer Journey Map?

  • Define primary and secondary personas for your product

A persona is a character profile or a fictional character. Personas help to understand the needs, experiences, behaviors, and goals of your users. If you want to create personas for your product, you may listen to my lecture in the online course.

  • Outline key events, persona's needs, and possible interactions with your product across different traffic sources
  • Create a comprehensive visual diagram that describes the journey of your primary and secondary personas

There are multiple visual tools that are available to create the journey diagram such as Mural, Gliffy, UXPressia, Lucidchart, Microsoft Visio, OmniGraffle, Miro, etc.

For outlining the required data in Step#2, I created the Customer Journey Map Template or a Canvas as below:

Customer Journey Map Template for an Existing Customer

Customer Journey Mapping Canvas for an Existing Customer

Enroll in the online course to download this canvas and learn more ->

Agile Product Planning: Discovery, Vision, Strategy, Roadmap - Create Business Models, Personas, Product Vision, Customer Journey Maps, Roadmap, and Product Backlog

 

Customer Journey Map Template for a Prospective Customer

Enroll in the online course to download this canvas and learn more ->

Agile Product Planning: Discovery, Vision, Strategy, Roadmap - Create Business Models, Personas, Product Vision, Customer Journey Maps, Roadmap, and Product Backlog

 

Watch the Customer Journey Mapping Lecture Here!

Continue reading→

Agile Anti-Patterns For Remote Teams

Posted on by

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 some agile anti-patterns for remote teams based on 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.

 

There are no quiet corners or conference rooms with a remote setting 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 in 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 the 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

Posted on by

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

Posted on by

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.

 

Leading with agility is an ability to step back, retrospect, gain a deeper perspective, make smart decisions, and take effective action. Leadership agility is not one single skill such as making effective decisions or inspiring people. Rather, it is a combination of skills working together that allows leaders to create the best customer and colleague experiences. 

 

"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 behaviors that drive 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

 

Leading with Purpose

The Covid-19 pandemic has created an economic crisis in the world and has disrupted supply chains. The pandemic led to a global labor shortage as people started to quit their jobs or resign early. The thought of returning to the office and the daily commute is discouraging for many people. People are willing to walk away from their jobs, switch employment, or take early retirement. Many businesses have now permanently embraced remote work while others are preparing for a hybrid model of working. During these times, it has become essentially important to encourage a sense of shared purpose that brings meaning to their work. 

 

Agile leaders lead with a purpose that inspires and brings people together. Their vision is manifested in their actions and their goals. Leading with purpose energizes people, attracts top talent, and builds a strong sense of community. 

 

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

 

The collaboration methods have changed tremendously due to the Covid-19 pandemic. During the pandemic, people could no longer have casual water-cooler conversations and thus started to explore available online tools that promote spontaneous ideation and collaboration. Most organizations adapted to new ways of working either remotely or in a hybrid environment. Some virtual collaboration tools that I found quite useful are Slack, Trello, Mural, WebEx Meetings, Zoom, Skype for Business, Microsoft Teams, Google Docs, One Drive, etc.  

 

"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

 

Practicing faster decision-making

Faster decision-making is an important skill to make choices that have the best chance of leading to a favorable outcome. For making decisions faster, you need to set a deadline or block your calendar to help you focus on the problem while avoiding distractions. Second, stop being a perfectionist and try to be more realistic in your problem-solving approach. The truth is that you will most likely not have all information you think you need and will need to embrace uncertainty.

 

Next, you should understand when and which decisions can be decentralized to reduce unnecessary delays. 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. 

 

Sometimes, the problem is having too much data or too many options to choose from. With so much data available at our fingertips, we tend to overthink and have analysis paralysis also called FOBO (Fear of Better Option). In his Ted Talk, Patrick McGinnis explains how to overcome FOBO and make faster decisions.

 

Embracing Lean-Agile Principles

The Lean-Agile Mindset is the combination of beliefs, behaviors, and attitudes of leaders who embrace the concepts of the Agile Manifesto and Lean thinking. Leadership agility requires leaders to 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?

Posted on by

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?

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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: