Kamlesh Ravlani, Author at Scrum Certification Training and Agile Coaching - Page 2 of 2
Who can become a Scrum Master?

Who can become a Scrum Master?

Who can become a Scrum Master?

Is there any particular background required to become a successful ScrumMaster?

Hi This is Kamlesh Ravlani, Scrum Trainer and Agile Coach with Agile For Growth. I am an Engineer by heart, and for many years I've worked as an Engineer, Team Lead, Project/Program Manager and Program Director before I moved to become a full-time Scrum Master.

In this video, I discuss:

> Is there any particular background required to become an effective ScrumMaster,

> I share with you the 10 most common backgrounds of ScrumMaster I've worked with, and

> I also give you a 5 point checklist to become successful in the ScrumMaster role.

The good news is, you don't need a specific background to become a Scrum Master. People having the skillset of Scrum Master can come from any field.

and, the not-so-good news is, it's hard and takes years of skillful practice to become an effective Scrum Master.

So before discussing who can become an effective ScrumMaster, let's understand the key skills required to perform ScrumMaster role, which are:

  • Facilitation
  • Teaching &
  • Coaching

Can you develop these skills? Why not!!

These skills help you to leverage your existing background in helping the teams you serve.

Now, let me share with you the 10 most common backgrounds I've seen good Scrum Master have come from:

10 most common backgrounds

  1. Program Manager, Project Manager
  2. Program Director, Director of Delivery
  3. CTO, CIO
  4. Product Manager
  5. Business Analyst
  6. QA Lead, Test Manager
  7. Technical Lead/ Developer
  8. DBA
  9. Customer Support Lead
  10. Release and Operations Lead



Are you one of them?. It doesn't matter if you are not.

You can still become an effective Scrum Master by following this 5 point checklist

5 point Checklist to become an Effective Scrum Master

  1. Are you adept at influencing people?
  2. Are you passionate to delight customers?
  3. Are you driven by the motive of serving your team?
  4. Do you have experience in the domain or the product that your teams are working on?
  5. Do you understand Scrum well?


Effective Scrum Master Checklist Infographic

Are you one of them?

It doesn't matter if you are not!

Depending on what background you come from, you may need to acquire new skills of Scrum Master role and you may also need to unlearn some bad behaviors that may hinder you from performing the Scrum Master's role effectively.

Such as- If you manage Finance, If you Write performance appraisals, If the Scrum team members report to you, you may have to explicitly let go of that organizational power and authority to be able to serve the team as Scrum Master.

Please tell me in comments, your thoughts, and experiences about who can become an effective Scrum Master?

7 Tips for Writing Acceptance Criteria with Examples

7 Tips for Writing Acceptance Criteria with Examples

Acceptance Criteria Definition

Acceptance Criteria defines how a particular feature could be used from an end user’s perspective. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing which establishes the conditions for the success of the feature.

Acceptance criteria could establish a boundary that helps team members to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behavior in happy path scenarios, it also guides the user experience when things don’t work as intended. It describes what would be verified by the acceptance tests.

When the product owner verifies particular user story acceptance criteria and the developed feature passes it, the development of the user story is considered a success. Pass / fail type results allow AC to form the basis of creating tests that can be automated and executed.

Tips for writing Acceptance Criteria


An essential aspect of writing good user story involves writing good acceptance criteria. It is the key to effectively testing the developed functionality. It allows the team members writing acceptance tests to understand the scope of the user story or Product Backlog Item (PBI).

How to define acceptance criteria? Here are some useful tips for writing AC for user stories. Some of the Scrum teams I’ve worked with preferred to use these ac tips as a checklist for writing good acceptance criteria. Acceptance criteria checklist helped with consistency and acted as training wheels for new team members. I encourage the teams to keep revisiting and revising these tips to fit their need. I would also forewarn to avoid using these tips as fixed rules.

7 Tips to write Acceptance Criteria | Agile For Growth

7 Tips for Writing Acceptance Criteria:

  1. Each product backlog item or user story should have at least one acceptance criteria. Hey, don’t take writing acceptance criteria lightly or think of skipping it.
  2. Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams. Write acceptance criteria after the implementation and miss the benefits.
  3. Each acceptance criterion is independently testable. Why shouldn’t it be?
  4. Acceptance criteria must have a clear Pass / Fail result. Write complex and long sentences at your own risk.
  5. It focuses on the end result – What. Not the solution approach – How.
  6. Include functional as well as non-functional criteria – when relevant.
  7. Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared understanding of the user story.

Acceptance Criteria examples

Product Backlog Item (User Story) example

acceptance criteria example for Pay Balance Due PBI

Example 1: User story and it’s acceptance criteria:

As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.

the acceptance criteria for this story could be:

  • Display statement balance upon authentication. Say for example $1560
  • Display total balance. For example $3560. Here the balance due from the current period is $2560 and past balance due is $2000.
  • Show Minimum payment due. For example $140
  • Show Payment due date. For example May 16th of the current month
  • Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
User Story example 2

acceptance criteria example for student performance PBI

Example 2: User story and it’s acceptance criteria:

As a teacher, I want to generate assessment report, so I can evaluate student performance.

the acceptance criteria for this story could be:

  • Show a student’s current assessment score.
  • Display past assessment score of the student.
  • Provide an option to Print / Save / Share. (By the way, this could be split as a separate user story by itself).
  • Display error message if service not responding. (If a team chooses to add the Error Message as their definition of done for all stories – where ever applicable, it could be omitted from the acceptance criteria).

Challenges with writing Effective Acceptance Criteria

Despite being simple to write, yet powerful, the task of writing acceptance criteria looks challenging for most teams. It’s not uncommon for teams to make simple mistakes and repeat errors when writing Acceptance Criteria. Some of the most common challenges and mistakes I’ve noticed with acceptance criteria from user stories I’ve seen in the real world are:

Pretty Narrow: Acceptance criteria is written very specific to a particular use case, scenario or technical approach.

Keep in mind, when you already have a solution in mind while writing the acceptance criteria, you end up leading your developers in that particular direction. In most cases, that may not be the optimum / best way of solving the challenge. Also being too narrow may mean that your testing may skip other user behaviors not specified in the AC. This increases the chances of missed testing, increases the risk of failure.

Very Broad: Acceptance criteria is written pretty broad.

Too broad acceptance criteria usually increase the risk of the user story being too bulky and may introduce fat in the features. Good acceptance criteria as discussed above should establish boundary so that the developers know how much to code and where to stop.

Complex: Acceptance criteria is complex, includes jargons and technical details.

Good acceptance criteria should be written in simple English and should be easy to understand. The key is to keep it simple.

What are the challenges you find with writing acceptance criteria?

Let me know in comments and I’ll address your most common challenges.

Who writes Acceptance Criteria?

Let me first burst a common myth that the Product Owner should write the acceptance criteria.

In fact, I recommend, you try ‘avoiding’ the Product Owner writes all the acceptance criteria. Why so?

Who writes the acceptance criteria, or who defines the acceptance criteria is not a matter of rules, availability or convenience.

What matters is – writing acceptance criteria (AC) should help establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building the product capability.

When you encourage the team members to write the AC, they must first understand the intended purpose of the feature and the outcome it must generate for the users.

Writing the acceptance criteria clarifies the scope for the team and also allows for the Product Owner to verify if the team and the PO have a shared understanding of the feature.

Alternately, Acceptance criteria may also be developed jointly by the development team and the product owner.

What is the right amount of Acceptance Criteria?

Well, if you’ve too many AC for a single product backlog item (PBI), chances are you could split it into multiple PBIs.

Tip: Have too many criteria as part of one story and chances are you’ll easily run into at least one criteria that isn’t passing.

That delays the delivery of that user story, which delays the feedback, ultimately increasing the risk of failure. I recommend, whenever you can, please go ahead and split the user story right there. Thank me later 🙂

acceptance criteria detail for user stories

Splitting user stories helps in keeping each user story small, improves chances of delivering it early, seeking feedback faster, hence reduces risk. Yes, there is effort involved in splitting the user stories as well.

Hence, the PO and the development team have to identify for each user story, what is a barely sufficient detail of AC. Photo source: Kenny Rubin, Innolution where Ken discusses the pros and cons of adding too many details versus no detail and establishes the need to identify what is barely sufficient detail to get started.

It’s important that your team members spend a little time and get good at writing acceptance criteria. It’s benefits are long lasting and ROI of the effort is simply too high to ignore.

Rule of Thumb: My rule of thumb for number of acceptance criteria is to have between 1-3 per user story. If a user story have between 4-5 of these, I start exploring options to split the story. If there are 6 or more criterion then the chances are the team won’t be able to implement it all in one sprint, definitely this story needs to be split in more than one.

Remember small user stories with lesser scope can be delivered comfortable within a sprint and presented to users for feedback. Early feedback reduces risk and impact of failure.


When to write Acceptance Criteria?

Acceptance criteria (AC) should be written anytime before the user story is deemed ready to enter the Sprint Planning. Usually it is written during the product backlog refinement meeting. AC can be progressively developed and added to a user story during the refinement. However it should not be kept for when the development team start implementing a user story.

“If we write and review the acceptance critera before implementation begins, we’re more likely to capture the customer intent rather than the development reality” writes Steve Povilaitis.

To ensure the AC is defined for each user story upfront, many teams add writing acceptance criteria for User Stories to their User Story Readiness Checklist. User Stories that do not have at least one AC can’t enter the Sprint Planning itself. Well, that shouldn’t prevent the team from exploring the intent or refining the AC after the Sprint Planning / before the implementation when the team members have conversations with the Product Owner.


What you should do now

1. If you’d like us to work with your teams — to dramatically improve your product management, product development, organizational agility, and growth (like we did for many clients from fortune 500s to young startups), then leave your inquiry and claim a free Agile Coaching strategy session. On this free phone consultation, one of our expert coaches will discuss your agility goals and suggest strategies to improve your team and organizational agility.

2. If you’d like to assess your team agility for free, go to our Agile Assessment, where you can instantly evaluate the current agility of your team and identify the gap between their current state and desired state. Or, if you’d like us to build your company’s in-house capabilities to be Agile (not for free), then contact us and we’ll discuss your requirements.

3. If you’d like to read further —  see our recent insightful Scrum articles

4. If you enjoyed this article, so will your friends. Why not share it on LinkedInTwitterFacebook and Email

Scrum Master Focus Survey

The survey aims to compare the Scrum Master's role as described in the Scrum Guide with the reality in organizations. With that aim, I'm set out to collect the real world insights from practicing Scrum Masters, about the Scrum Master role and the focus of Scrum Masters.

If you are currently performing the Scrum Master role, please answer this survey to maintain a high relevance of the answers collected. We value candid answers based on real world facts over answers based on future aspirations or opinions.

What is a Scrum Master, How to Become a Certified ScrumMaster?

What is a Scrum Master?

Scrum Master is one of the three roles that make up the Scrum Team as described by the Scrum Framework.

The Scrum Master role is specific to Scrum and is a critical aspect in achieving the ambitious goals of helping the team and the organization be adaptable to rapidly changing customer needs through continuous inspect and adapt.

To be adaptable the organization must develop the capability to continuously seek feedback from the customers about their needs and adapt their approach to meet these needs gracefully.

The Scrum Master acts as a catalyst to this capability development within the team and the organization. Scrum Master achieves this by educating, facilitating and coaching the development team, the Product Owner, and the organization.

While the Product Owner focuses on improving the product ROI by defining what is right to build, the development team focuses on building the product right, the Scrum Master acts as a servant-leader and focuses on building a high performing team to maximize the value created by the Scrum Team.

Scrum Master service to the Product Owner

As per the Scrum Guide, the Scrum Master collaborates with the Scrum Product Owner and serves by:

  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Understanding product planning in an empirical environment;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.
Scrum Master services to the Development Team

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Scrum Master service to the Organization

The Scrum Master according the Scrum Guide, is also responsible to serve the organization in below ways. However, most Scrum Masters fall short on serving the organization.

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

How to Become a Certified ScrumMaster?

The Scrum Alliance is one of the most reputed and popular certification body. The Certified ScrumMaster certification from Scrum Alliance is the most credible certification as Scrum Alliance carefully through a rigorous process wets out the Certified Scrum Trainers. This is how you can get a ScrumMaster certification:

  • Attend the 2-day Certified ScrumMaster (CSM) training facilitated by a Certified Scrum Trainer (CST).
  • Read the Scrum Guide and review the CSM participant workbook/reading content provided.
  • After successful two days workshop, the CST recommends your name to Scrum Alliance.
  • Scrum Alliance emails you a link to take the online CSM test. [Take a mock CSM Test online]
  • Take the CSM test and get 24 (out of 34 multiple choice questions) correct answers to pass the test.
  • Upon passing the CSM test, download your Certified ScrumMaster certification from your Scrum Alliance member account dashboard. And here you are a Certified ScrumMaster 🙂

How difficult is it to become a Scrum Master?

Becoming a good Scrum Master is difficult but not impossible.

Start getting good with these Top Scrum Master Skills.

In 2018, getting a job of a Scrum Master is relatively very easy. The reason? high demand for the Scrum Master role and less supply of good Scrum Masters.

Most companies have not educated their hiring and recruitment staff to understand the role of the Scrum Master and hence many recruiters simply compare a candidate's profile against a template given to them.

In such cases, the Scrum Master's selection process would look for:

The candidate has a Certified Scrum Master (CSM) Certification or a Professional Scrum Master (PSM) Certification.

 * Has experience working as a Scrum Master recently.

 * Can facilitate Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective meetings.

 * Can train our employees on Scrum, XP, Lean, Kanban, BDD, TDD, DevOps, (they may list every new Agile framework that comes to market)

 * Can act as an Agile Team Coach (usually they mean can tell our teams how to do Agile)


You see?

If you know your stuff, you can easily crank the interview and get in as a Scrum Master.

Who can become a Scrum Master?

In this video, I discuss 5 essential elements to becoming an effective Scrum Master.

Here, I list 10 most common Scrum Master backgrounds that I've observed the Scrum Masters I've worked with came from.

Living without TechDebt

Living without TechDebt

TechDebt Free

I grew up in an educated middle-class family and was taught to #Save rather accrue #Debt. I don’t remember my family applying for a loan to buy an expensive house hold appliance or to go for a luxury vacation abroad. I guess most parents teach their kids to manage their spending and live within means.

I saw my parents live debt free. That encouraged me to think what was really important to buy.

It forced me to make sound choices.

The need to live without debt taught me to say No.

No to unwanted stuff. No to things that were not urgent. No to things that were appealing on the surface but didn’t fit into the bigger scheme of my world.

If you’ve read Robert Kiyosaki, you may be familiar with his advice of using Other People’s Money (OPM) and one of the traditional ways for using OPM is to get a loan. Many got sucked into the trend. Now they can buy everything they may need and get it on loan.

I would like to call is a systemic dysfunction.

Systemic dysfunction is created not by one person or one institution. It also doesn’t develop just because of one or few instances.

Systemic dysfunction may manifest in the system in various forms and we start to see symptoms much later.

Sure we all remember the 2007 financial crash and its ripple effect on most of the economies of the world.

I observe similar and growing trend in the world of software product development.

Everywhere there is pressure to deliver more. More than the available time at hand. More than the people (at the front) can practically deliver.

In the pursuit of Growth, the Sales teams are assigned sales quota that’s beyond challenging.

Marketing and Product Development usually find themselves dragged into the game to deliver more.

The product delivery teams and IT teams are usually at the receiving end of this rat race.

To secure their job, they end up saying Yes, more often than is realistic.

The Product Team creates a pipeline of requests to add more features. More new features in the product.

The product developers end up delivering new features.

There is less time to think of quality and developing these features right.

The code is just good enough to work. There is a mountain of unfinished and poor code that the products are built on.

The developers are accruing more Technical Debt.

It’s a systemic dysfunction.

Not created by one developer or one team. Not created during the implementing of one feature or one product.

TechDebt is in every code poorly developed and is being accrued with each new request that needs to be delivered in rush.

Without empowerment, Developers feel that giving in to the demands of delivering more is the only option. The Product Owners in most organizations feel the same as they feel the pressure from the top brass.

Until someone chooses to stand up and says No to cutting quality.

Until someone says No to poor coding practices.

Until someone says No to skipping refactoring.

Until someone says No to delivering buggy product to customers.

people will keep giving in to the demands, team members will continue to be stressed, continue to cut corners – knowingly or unknowingly, and feel bad for delivering poor quality.

Would that be you? Would you be able to stand and say No to cutting quality, No to delivering poor quality products?

If yes,

Here are 3 steps you can take to immediately curb the TechDebt from growing further:

Step 1: Acknowledge and make transparent the current level of TechDebt. If it’s visible and everyone keeps looking at the TechDebt level, it’ll be easy to persuade everyone to address it. I bet, most teams don’t even visualize their existing level of TechDebt. Do that.

Step 2: Block some time on calendars to identify, list and address the TechDebt. If no one is spending the time to address TechDebt, it’ll only keep growing.

Step 3: Identify a limit of TechDebt that your code can have at any moment of time. Once the TechDebt level increases the identified limits, fixing it will become the highest priority – more than developing new features.

Now think for a minute:

What if your product owners and entire team collectively agreed and pledged to live #Techdebt free?

How will living #TechDebt free look like in your organization?

Hiring an Agile Coach

Hiring an Agile Coach

If you’re a leader of product development and/or delivery, you would’ve found self hunting for an Agile Coach at some point of time. Hiring an Agile Coach to help your product development teams becomes a natural step in mid to large size organizations, after you’ve trained your people and they’ve been breaking their head for sometime – trying to solve the How to Become Agile puzzle on their own.

I can share a list of 20 things to look for when hiring an Agile Coach, however, I’ll be generous and I’ll only share with you my top two.

Why only two?, you ask. Well, Agile Coaches can come from a wide variety of backgrounds and can have strengths in wide ranging aspects. So there isn’t a single checklist on which you can measure each of the Agile Coach candidate.

Here are my top two areas that I look for when hiring an Agile Coach,

First point to look for in an Agile Coach (when looking for a process coach** – the most common one) is if they’ve helped build high performing teams as a Scrum Master (when following Scrum) – replace Scrum Master with a XP / Kanban /…. practitioner based on the framework you follow. This aspect works and is very common-sense type, however it’s also most frequently ignored, I’ll tell you why, how and in which cases – later.

Coming back to the point. If someone has worked in the trenches before getting into coaching they can very well foresee many systemic / deep rooted challenges within the team and the organizations while looking at the symptoms. Let’s be practical – in a product based organization, there isn’t much time allowed for the development team to do a root-cause analysis of each impediment or issue they come across. Here you can benefit from having an Agile Coach who has past experience working as Scrum Master and can help the team pick, which are high impact issues worth spending time on and resolving. Just to be clear – I’m not saying that your teams should always do what the Agile Coach says or completely transfer this responsibility to her, as sometimes she would be wrong as well – due to having little context of your situation and challenges than your teams. Your experienced Agile Coach would also be able to share real life stories from his past experiences when they see your teams struggling at the Sprint planning, or splitting PBIs or not getting much value from retrospectives, or struggling to order the product backlog, etc.

Without having real experience as a Scrum Master, your agile coach could possibly be coaching the organization in to a completely incorrect direction. If she doesn’t have real experience of facing a wide array of challenges such as helping teams transition from command-and-control to self-organization, from silos to collaborative work, from top-down to shared ownership, from single function expert groups to cross-functional teams, of shielding the team from traditional mindsets and people in power, of battling with internal politics and resistance, of removing impediments, of influencing without having authority, of serving the team and keeping the team ahead of their own interest, etc…. the coach would only play based on what they’ve read and heard from others – significantly limiting team’s potential to produce great results.

Once in a while, I came across Product Owners who took interest in mastering Scrum and were really interested in helping the teams get better at implementing Scrum. They cared for the team performance. I guess such Product Owners can also make effective Agile Coaches.

Second aspect to look for in an Agile Coach (assuming the team is developing software products and using Scrum) is if they’ve ever worked on a Scrum Team where the PO and the dev team were in one building and collaborating on daily basis. Without having experienced this is like talking about Switzerland without having visited it. While reviewing candidates who worked particularly in service based (vendor) organizations lacked this knowledge. They were only experienced working with the vendor team at offshore, but didn’t have real experience working with a Scrum Team. Their experience and knowledge is limited to 1/3rd of the actual Scrum Master responsibility as listed in the Scrum Guide. These candidates significantly lacked in skills to influence any significant change with respect to how the Product Owner (usually from the client organization) worked as well as how the organization (client organization) transformed.

These candidates almost always oblivious to the actual organizational level challenges due to which the transformation initiatives were getting failed or stalled. What they knew was, my project ended and I was moved by my employer to another project. This person simply is a facilitator of the Scrum meetings (when implementing Scrum), not much more than that – in most cases.

Both of these points usually filter out all types of less than deserving Agile Coach candidates.

Now, what else I would look for in the Agile Coach candidate?

  • Experience working with leadership team,
  • Experience with organization design,
  • Experience Facilitating-leading change initiatives, (not the top-down change initiatives)
  • Knowledge of more than couple of Agile frameworks / techniques, etc…..

that list is long and your list should be specific to your situation.

What is your experience with hiring Agile Coaches for your product development teams?

Does your Scrum Master Inspect and Adapt?

Does your Scrum Master Inspect and Adapt?

The empirical approach to product development doesn't have to be limited to the fine tuning the product direction, it's equally powerful when applied to the process of developing the product.

Sprint Retrospective meeting provides an in-built approach for the Scrum Teams to inspect and adapt. I observe in most organizations (almost 9 out of 10 times), everyone in organization is looking up to the development team to retrospect and improve their process. Most of the time the implicit desire is for the development team to deliver more features in less time.

What is almost always overlooked is if the Scrum Master is performing her job effectively in helping the Scrum Team become effective, creative and flexible - what the Scrum Team is designed to be.

Usually because the Scrum Master is the only most-Scrum-educated person available. No one (dares/) holds her responsible for improving at her own job, at what is she supposed to do.

Why most of the Scrum retrospective meetings neglect to inspect how the Scrum Master performed during the Sprint?

One common oversight is that Scrum Master by default sends the meeting invites and takes up the role of the facilitator during the Sprint Retrospective meeting. The facilitator by definition doesn't participate / contribute to the conversations as her focus is to hold the space and create structure for the participants to contribute effectively, resulting in the Scrum Master to usually escape the periphery of the retrospection.

Scrum Guide calls out the Scrum Master's service as;

Facilitating Scrum events as requested or needed - Scrum Guide

One good approach to worth giving a try is, to rotate the facilitator and allow the Scrum Master to participate in the Sprint Retrospective meeting with the Scrum Team.

By rotating the facilitator, the Scrum Master also gets the chance to participate in the retrospective, reflect and share her own perspective and analysis of her performance. If she shielded the team well, if she was effective in helping the team to remove the impediments, if she did good in coaching the dev team, the product owner, as well as the organization, etc..

Does your team care and discuss if the Scrum Master performed her duties well during the sprint?

Becoming a real effective Scrum Master is tough journey. Those who are open to seek feedback and look for opportunities to continuously improve their own game, also stand chance to inspire their teams and leaders to improve.

What are your thoughts about the topic?

If you are Scrum Master, how do you ensure to inspect and adapt your own performance?

5 Key Lessons for Product Based Enterprises from Army

In September 2016 Indian special forces carried out surgical strikes at 7 terrorist launch pads across the line of control (LOC) in POK. Read more….

Surgical strikes require detailed and exhaustive planning. It needs to be carried out with absolute precision to achieve the objective of taking down targets with either no or minimal collateral damage.

In an ideal world, there shouldn’t be a need for such operations as everyone should aim to live peacefully and let others live peacefully. No terrorism, no surgical strikes. However the reality today is far from ideal.

There are many pearls of strategy from this surgical strike that corporations can learn and get better at launching major products in markets. In this article, Let’s focus on that aspect:


1. Sense and Respond rapidly to opportunities/market needs:

The customer and market factors beyond your organization’s control may present opportunities outside of your regular operations/product features. Organizations that can quickly sense these opportunities and respond swiftly may find themselves gaining market and continued loyalty from customers. That’s agility.

Organizations that are not capable of sensing such opportunities or acting upon these quickly may see themselves becoming irrelevant in the new market. Remember Kodak and Blackberry?

Fact: Of all the Fortune 1000 companies as of 2003, 70% disappeared from the Fortune 1000 list by 2013. The rate of change in 2017 has only increased.

Tip from the real world: One serious flaw we observe with bureaucratic and large organizations is that smart people working in these organizations may already have observed new opportunities/needs, however, may feel unsafe to try out new ideas due to fear of failure and the consequences of failure on their job.

Encouraging every employee to experiment and innovate may not work on its own, leaders must act in line with what they preach and also allow freedom for the employees to make choices safely.


2. Execute Flawlessly:

It’s not luck or coincidence. Achieving excellence in Product development and product launch takes years of effort to build this capability. Being excellent at connecting with customers, understanding customer challenges, translating the vision into solutions, developing quality products rapidly, launching solutions to market early, promoting and selling the products through multiple channels and partners etc., all at the same time, can’t be a sheer coincidence every time.

The more you sweat in training, the less you bleed in combat. Richard Marcinko.

To become agile, organizations should identify process and practices to continuously improve, enhance the products, optimize the organizational system, avoid short cuts, avoid local optimizing and strive for breakthrough innovations in products as well as processes.

Executing flawlessly is also a result of choosing your battles. If people in your organization are always busy, always fire-fighting, they have no time and motivation to experiment, strive for quality and focus on excellence. If your company offers 30 varieties of fruit jam, most likely your company does not have a single world-class variety of jam.

Tip from the real world: Check this: Tesla only sells 2 models of cars (3rd is in making) v/s GM who has 24+ models. Apple offers 3 models of laptops v/s HP which sells 24+ models. Google constantly identifies products that do not meet it’s benchmark performance and retires these products. Facebook keeps disrupting itself regularly to get better. Hope you get the point.

To be able to execute flawlessly, your organization must focus on few key offerings, and constantly up the game. At Agile For Growth, we are focused on offering Scrum Training and politely deny serving clients with other training requests. It allows us to focus on what we do well.


3. Involve Stakeholders Early:

A visionary leader finds a common purpose and crafts an inclusive mission to bring all stakeholders together. Involving all stakeholders early avoids the chances of missing out on key participation and support from the stakeholders as well as helps avoid consequential resistance later.

It’s difficult to find harmony when trying to align multiple stakeholders particularly in large enterprises. However, that shouldn’t be an excuse from involving stakeholders early. In today’s market, stakeholders are all those involved in the success of your product that includes employees, vendors, partners, and customers. Have a strategy in place to engage all stakeholders contextually and at an appropriate time. Sooner the better, in most cases.

Immediately after the surgical strike, the Indian government briefed the key leaders of the opposition, called for an all-party meeting, informed the UN and other key countries. The India head of military also called up his counterpart in Pakistan and briefed him about the operation. A Press conference was planned and called for immediately. A plan was already in place to handle any retaliation.

Tip from the real world: Involving stakeholders early allows you to identify and address any resistance early. Having satisfied stakeholders offer you additional support in terms of introductions, referrals, testimonials, and free word of mouth publicity. Many new and breakthrough products today are co-created with customers involved right from the inception of the product. It’s not uncommon for startup’s to open up their Product Roadmap and allow their customers to vote on the upcoming features.

Tools: Trello and Roadmap.space are good free tools to get started.


4. Build the Ecosystem:

The product gains tremendous value when there is an eco-system around it which enhances its usage and benefits. Apple’s App store is one of the key examples that helped expensive iPhone take off against the established and low priced Nokia and Blackberry. Most product companies today offer APIs that allow developers to build third party applications and to enhance the value of their product.

Tip from Real World: At Agile For Growth, we offer Scrum training and Enterprise Agile Coaching. All clients engaging us for Scrum training workshop, get 10 additional value-adds and bonuses that allow the training participants to continue getting value even after the workshop. That gets them real world benefits from implementing Scrum concepts, techniques and tips. Beyond the 2-day workshop, we’ve designed a broader engagement and experience for our workshop participants. These bonuses significantly enhance the value our customers get from engaging us. These value-adds, almost payback for the training investment.


5. Build Trust First:

India through it’s sensible and responsible behavior over the years built trust with allies and parties, which helped it gain support from many countries when deciding to carry out surgical strikes across the LOC. Don’t forget that you DO NEED strong support of stakeholders, partners, customers, and employees when taking big and risky bets. If your organization has worked for it and earned trust, getting this support becomes a relatively easier task.

Being adaptive, responsive, nimble – Agile, at the organization level is a choice that everyone in the organization needs to make and commit to. It’s a tedious journey that requires a fair share of taking tough decisions, disrupting the status-quo, being ready to fail, traveling uncharted territory and tapping into the collective intelligence of everyone involved.


What is your key takeaway from these strategies? I’m interested in learning it!

Six powerful hacks for Scrum Masters to Gain Influence without Authority

Six powerful hacks for Scrum Masters to Gain Influence without Authority

As a Scrum Master you have one of the toughest yet incredibly meaningful role to play in improving the product development environment in organizations. You don’t have any positional power and authority in the organization, as none of the development team members report in to you. Despite lack of authority and power, your role is highly dependent on enormous amount of influence to be able to educate and coach the development team, the product owner and the organization at large. High level of influence helps you become effective in delivering your responsibilities.

The lack of enough influence, could cause the Scrum Master to quickly succumb to an administrative assistant role without even realizing it.

To be effective you would need influence capital at the team level, with the product owner and at the organization level.

Like every Scrum Master you may wonder, how do I gain influence? Here are six ways to try:

  1. Scrum-Master-Influence-Invite-Team-Select-YouInvite the team to select you.

Don’t get assigned or imposed on the team. If you are interviewing for a Scrum Master position with a team that already exists invite the team members to interview you as well. If you are being transferred within an organization from one team to another, it’s easier for you to setup time with the members of the new team. Use this opportunity to let them interview you. When the team members select you to be their Scrum Master, they are much more open to your insights and coaching interventions. They’ve brought you in so they are invested in your success. Though this practice is very common in smaller companies and smaller teams, many Scrum Masters I come across in larger organizations are assigned to the teams (read: top down). This strategy always exposes you to potentially getting rejected by the team and that’s a good thing. Would you rather join a team and get rejected by them four or eight weeks later? Hey, it saves you from bigger failure and allows you to explore other opportunities immediately.

Scrum-Master-Influence-Ask-QuestionsNot yours. Not the manager’s. This may seem counter-intuitive to you. For the Scrum Team to perform well it needs to self-organize and self-manage itself. As a Scrum Master be the facilitator, so the team can craft it’s agenda and own it. The Product Owner ensures this agenda is in-line with the organization’s larger objectives and vision. The ownership and commitment increases many folds when the team has crafted the objectives, plans, improvement areas, quality standards and performance goals on it’s own. It increases the engagement and the team members hold each other accountable to high standards. When you commit to serve team’s agenda, not only the team trusts you more, they genuinely listen to you and collaborate with you.

  1. Listen Emphatically

Scrum-Master-Influence-Listen-EmpathicallyScrum exposes dysfunctions and that’s an uncomfortable position to be in for most teams. While the ideal and expected answer to such situation is to solve the dysfunctions, it’s easier said than done in most organizations. Change isn’t easy and it’s cousin resistance usually, accompanies change. As a Scrum Master open up your ears and empathetically listen to your team’s challenges, you would understand the context, dependencies, underlying assumptions, cultural biases and limitations better. When you actively and emphatically listen, you get to know the person well and build a relationship with them. The one who is talking could get better clarity about their situation and thoughts, allowing you to effectively offer your help to them.

  1. Ask questions.

How would asking questions increase my influence? you ask. Asking powerful questions and listing skills go hand in hand. Powerful questions could provoke deeper insights and challenge the person to think differently. As a Scrum Master when you genuinely ask open-ended powerful questions, without bias towards an answer, you empower the team members. It allows them to explore the options they may already have access to and find solutions for themselves. When someone identifies an approach they want to try to solve a challenge, you would not need to persuade them. Why? It’s their approach. You could simply ask them if they need your help keeping them on track. You could hold them accountable towards action and results through regular check-ins.

  1. Constantly Self Analyze.

Keep analyzing how your behavior and your service to the team, the product owner, and the organization. Seek feedback, experiment frequently, and share your learning with others. Be vulnerable, it’s ok. When you constantly self-analyze in the pursuit to improve your skills, your behavior, your own work, your team takes a note of it. The influence you gain through walking the talk would be a tremendous boost in getting team’s participation and buy-in. Guess what will be your team’s response when you invite them to analyze team’s communication, processes, behavior, and performance?

  1. Master Scrum.

Yes, it’s critical that you Master it. Learning Scrum, mastering to implement it and helping the team(s) implement it is an ongoing and cautious effort. Learning Scrum doesn’t have to stop after you attend 2 day Certified ScrumMaster (CSM) training or become a Certified Scrum Professional (CSP) – this is where mediocre Scrum Masters stop. Don’t stop there. Equip yourself with skills you need to thrive in your context. Experiment new ideas, facilitation techniques, activities, and games, see what works. Your mastery of Scrum will directly impact the benefits your organization could realize from implementing Scrum and that could credit a lot of influence in your account.

PS: When I got my CSP credentials, I architectured it to be an opportunity to accelerate my learning and implementing Scrum with new fervor. It gave me access to lot more resources and boosted my confidence. When I was told – this is how we do it here, I didn’t let it be that way. When I was told – oh, we can’t do that here, I didn’t accept it. I kept exposing dysfunctions and challenging the status quo. It has helped the teams, it has helped the organizations I serve and that has helped me tremendously.


Hey Scrum Masters, would you like to self-assess your level of influence? Take a 2 minute assessment here.

I didn’t intend above list to be an exhaustive one. I’m curious, what has helped you gain influence in your practice? Would you share it with me?

"How have you gained influence in your environment?"

The Product Owner Puzzle

The Product Owner Puzzle

A dedicated and effective Product Owner is critical for a Scrum Team to deliver exceptionally successful products that delight customers, gains market share and yields high ROI for the organization.

Jenny is a director of product development at a global organization that is in the midst of a massive transformation. The market they operate in, is evolving rapidly, the customer needs they specialize in serving well are fast changing and the way they organize and run the enterprise must adapt to demands of the newer generation of knowledge workers.

Jenny is smart and thoughtful leader. She is responsible to serve millions of users every day via a portfolio of web and mobile applications. Her annual budget sits north of $20 millions and brings in close to a $1 billion in revenue.

To help their organization become adaptable, Jenny and her team started implementing Scrum framework a year ago.

I am Kamlesh, Agile/Lean coach and trainer. Jenny, her team members and I are meeting this morning at 9. Our discussion will focus on the opportunities for her team to get better at adapting to changing requirements and aligning a large number of team members, partners and vendors. Jenny responded to a brief questionnaire I sent her last week. In her response she mentioned, gaining better Net Promoter Score is one of her primary focus. Jenny and I have known each other for some time and I’m looking forward to meet her.

Me: Good Morning! How are you?

I’m well. Thank You. Jenny is energetic. She introduces her colleagues Alex, Srini, Deb and Priya.

We greet each other, and walk to a conference room. Freshly brewed coffee is waiting for us. Jenny and team has come ready for our conversation and I can guess, is eager to go to the next level in their Agile journey. Priya has nice visuals of their products on two flip chart sheets. She is posting these sheets next to the whiteboard while we sip the coffee and share couple of laughs.

Jenny kicks off the meeting with a brief 30,000 feet introduction of her portfolio. After her, Deb gets up to give us an overview of the product and their SCRUM implementation.

“It (the Product) comprises of multiple applications which are tightly coupled. We aim to reduce delays due to one team waiting for another team to deliver a service or functionality. One cross-functional team supports one application. All teams follow Scrum except one team. Jenny works with the marketing and Priya assists her. Priya also works with the BSAs to refine the requirements. Alex acts as a Program Manager, manages the budget, hiring, procurement and working with outside interfaces. Srini and I play the Scrum Master role.

So who is the Product Owner? I eagerly posed the question to Deb.

“Who is the Product Owner?”

Deb is looking at Srini with a question mark on her face. Srini turns toward Jenny.

There is a pause and a shift in the energy in the room.

What do you mean?” Jenny jumps right in. She opens up her shoulders and re-adjusts herself on the chair.

I continue to look at her without any reaction.

“We don’t have a “separate” Product Owner; Jenny indicates in quotes.

“No Product Owner?” I take a pause. “Please help me understand, who talks to the customers? who owns the Product Backlog?” I continue with curiosity. “and who prioritizes features?”

Priya pitches in, We all work on that. Priya’s response brought relief on everyone’s face. Srini adds, We have shared ownership of the Product Backlog. Anyone can add user stories, defects, technical debt to the Product Backlog. Team members collectively refine and volunteer to pull the items.

It’s great to know that you’ve a culture that encourages collaboration and shared ownership.

Does that mean you all play the role of a Product Owner?”, I ask firmly.

“We, Product Owners? not really” Srini replies.

Let me ask you couple questions to clarify this further,

“Who tracks the release? I ask.

I do. Jenny says it calmly and confidently. “Alex helps me.”

And who decides, what’s the most valuable thing the team should work on first?”

I decide that. Jenny replies with a firm voice.

Would you say, you are the Product Owner? I ask.

I, Product Owner?” Jenny thinks and carries on, “Priya helps me with the information and with making decisions. We both remain in tight sync our marketing group. They give us the priorities.

And who talks to the customers?

Marketing. Priya has a clear answer.


“From what I’m hearing, no dedicated Product Owner supports this product.”

Everyone nodes. I clear my throat and explain,

From my experience, I can say, it’s critical to have one dedicated Product Owner supporting one product. The Product Owner ensures that customers are served well and the organization gets a higher ROI from it’s investment. She collaborates with customers, stakeholders and the team members. She is responsible to identify and create high customer value and make budget allocation accordingly.”

Everyone is silent and curiously listening. After a brief pause, Jenny goes,

“I think,” she looks at everyone, “if we’ve got a dedicated Product Owner, we can resolve some of our pressing challenges immediately.”

I ask, “How will your customers feel?” Everyone nods and smiles!!


Hey, I invite you to explore within your team and organization.

    Who’s the Product Owner?

Want new articles as they get published? Subscribe to our Awesome Newsletter.