Tag Archives: Agile

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

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:

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:

Agile and Lean

Posted on by

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

Posted on by

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. 

What are the 12 Agile Principles?

Posted on by

What are the 12 Agile Principles?

What are Agile Principles?

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

 

12 Agile Principles Explained

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

12 Agile Principles - Customer First

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

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

 

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

12 Agile Principles - Welcome Changing Requirements

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

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

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

 

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

12 Agile Principles - Deliver Working Software Frequently

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

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

 

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

12 Agile Principles - Collaboration

Agile Principle 4 - Collaboration                                                                                                    Photo by rawpixel on Unsplash

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

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

 

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

Agile Principle 5 - Motivation, Support, and Trust

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

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

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

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

 

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

Agile Principle 6 - Face-to-Face Conversation

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

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

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

 

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

Agile Principle 7 - Working Software

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

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

 

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

Agile Principle 8 - Constant Pace

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

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

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

 

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

Agile Principle 9 - Technical Excellence

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

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

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

 

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

Agile Principle 10 - Simplicity

Agile Principle 10 - Simplicity                                                                                                Photo by rawpixel on Unsplash

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

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

 

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

Agile Principle 11 - Self-Organizing Teams

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

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

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

 

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

Agile Principle 12 - Inspect and Adapt

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

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

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

 

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

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

Kanban Boards – Practical Examples

Posted on by

What Is a Kanban Board?

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

 

Sample Kanban Boards

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

 

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

DevOps Kanban

Sample Kanban Board - DevOps

 

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

 

 

 

Sample Kanban Board - DevOps

 

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

 

Sample Kanban Board for Application Development

 

 

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

 

 

Let's take a practical example of a platform team that receives multiple requests from different application teams every day. Here’s a sample Kanban board to visually track their onboarding requests.

 

Sample Kanban Board - Platform Team

 

 

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

 

Sample Kanban Board - Buying a Home

 

 

Next, let's consider another example of a personal Kanban board. In this scenario, you need to sort your house over the weekend. You decide to organize your work and reduce task-switching by creating a Kanban board. Here’s a sample board for such a scenario. 

 

Sample Personal Kanban Board - Sorting My House

 

 

Now that you have seen a few sample Kanban boards, will you be able to create one for yourself? Share your board in the comments section below. Don't forget to apply a WIP (Work-In-Progress) limit to your board.

 

More articles:

 

Other Books on Agile and Lean: