In 2017, a couple of developers on my new team approached me with a strong feedback; they didn't understand the stories / requirements I was providing them. In fact, the stories barely had any details of how the requirement was to be fulfilled for our customers. They were frustrated and I didn't know any better because that's how I had always provided stories. I didn't want my developers to be frustrated, nor did I want my customers waiting for their requirements, so I asked my developers how they wanted their stories. What followed was the most amazing video I had ever seen until then - Josh Darnit's Exact Instructions Challenge.

It's amazing, a father asks his kids to provide with the exact instructions to make a peanut butter & jelly sandwich. Initially they fail but finally they manage to write the best instructions there could be to make the sandwich making their father (read customer) very happy and no longer hungry. That's how I should be writing my stories they said, as detailed as it can be with no room for ambiguity and that's what I did. My developers were happy, my manager was happy, my customers were happy. 2021 saw an explosion with re-share of this video by many on LinkedIn, tagged the importance of writing detailed stories and it was appreciated by hundreds if not thousands of comments. Today however, I tag this practice as an Appreciated Anti-Pattern.

What is an Appreciated Anti-Pattern? These are practices when used under a particular context prove to be counterproductive however the negative effects get camouflaged pretty well to the extent the practice receives appreciation for its efforts. And there are tens of such practices just in the space of Business Analysis alone, which is also a book that I wish to publish soon (no kidding). Take the Exact Instructions Challenge for example; yes it helps the team receive their customers' requirements on a platter which is great and highly appreciated; at the same time, it kills the conversational-negotiable-lightweight aspect of User Stories that leads to loss of self-organization, collaboration, and innovation to a great extent.

Unfortunately what I've observed is that I have spent years making this appreciated anti-pattern visible to teams after teams; in-fact a major portion of my work (life) revolves around this. And yet not many of my clients have been productive to embrace it fully; I don't blame them, it's not easy, but there's a way (a few ways actually). An extended version of the Zero Defect Policy is my way of tackling the Exact Instructions Challenge that not only improves the quality of our products but makes the teams more self-organized, more productive, more collaborative, and more innovative. Now why wouldn't one want that? That's my talk.

Note: Although I have run a number of workshops around this topic, I have never delivered a 20 minute talk around this before so please bear with me while I prepare & submit a shorter (more impactful) version of this topic for your review.

During Agile India 2019, I presented SLICE as a way of conducting experiments to embrace and improve agility. Here's the sequel to the original experience report.

This workshop aims at assisting the audience to experience the SLICE way of experimenting in a Liberating Structures based setup. The workshop starts with

1. S election of Hypothesis using "25/10 Crowd Sourcing" Liberating Structure.
2. L earn more about the hypothesis using "1-2-4-All" Liberating Structure. Create groups.
3. I mplement the hypothesis with the most apt Liberating Structure as taught by the facilitators (4 facilitators).
4. C reate collaterals after the timebox expires.
5. E xpand collaterals to other teams and repeat (thrice)

The purpose of this workshop is to provide the audience with an experience of SLICE and Liberating Structures in a pragmatic manner.

The story goes ...

During the Agile Coach Camp at Agile India 2019, we had an interesting discussion driven by Woody Zuill around the concept of Organisational Inertia. This has been a topic of research since the early 80s with the newest research in 2000s as well. The research basically revolves around two aspects:

1. An organisation's incapability to keep up with major shifts
2. The resistance towards change

These don't necessarily stop change from happening but considerably slows down the shift. With organisations struggling to survive in a VUCA world, Organisational Inertia becomes one of the critical factors for consideration. Enter, an Agile Coach! Our industries have heavily invested in them in the recent past and continue to do so in order to help them survive in this VUCA world. Shane Hastie addresses this as the Golden Age of Agile Coaching in which coaches can help the poor souls navigate themselves during a period of turmoil. I respect that.

But my evil mind links the concepts of Organisational Inertia and the Golden Age of Agile Coaching differently; so during the Agile Coach Camp, I asked folks to run a Thought Experiment which I also mentioned in my talk during Agile India 2019.

The hypothesis is: "We can deploy Agile Coaches in organisations and hopefully the organisations will overcome their inertia in 10 years to provide a better work experience to their employees. Contrarily, if Agile Coaches cease to exist, organisations may crumble under their inertia in 5 years and the ones left will be great places to work" ... from a Behavioural Economics standpoint, the second option seems better.

Being a SLICE fundamentalist, I decided to run this hypothesis and began my experiment on 3rd June 2019, the day after I finished my last batch of ICAgile's Agile Coaching training. At the time of submitting this proposal, it hasn't been very long since I started the experiment, and it hasn't been easy to deliberately take a step back from coaching interventions. The observations have been interesting (if not amazing) so far and this is my experience report that I wish to share during Agile India 2020.

My plan is to run a set of experiments until 31st December 2019 and then decide my way ahead. I mention below the observations so far that I wish to share in my talk but there may be other experiments that I'll share if provided a platform at Discuss Agile Day Pune 2019.

The story goes ...

During the Agile Coach Camp at Agile India 2019, we had an interesting discussion driven by Woody Zuill around the concept of Organisational Inertia. This has been a topic of research since the early 80s with the newest research in 2000s as well. The research basically revolves around two aspects:

1. An organisation's incapability to keep up with major shifts
2. The resistance towards change

These don't necessarily stop change from happening but considerably slows down the shift. With organisations struggling to survive in a VUCA world, Organisational Inertia becomes one of the critical factors for consideration. Enter, an Agile Coach! Our industries have heavily invested in them in the recent past and continue to do so in order to help them survive in this VUCA world. Shane Hastie addresses this as the Golden Age of Agile Coaching in which coaches can help the poor souls navigate themselves during a period of turmoil. I respect that.

But my evil mind links the concepts of Organisational Inertia and the Golden Age of Agile Coaching differently; so during the Agile Coach Camp, I asked folks to run a Thought Experiment which I also mentioned in my talk during Agile India 2019.

The hypothesis is: "We can deploy Agile Coaches in organisations and hopefully the organisations will overcome their inertia in 10 years to provide a better work experience to their employees. Contrarily, if Agile Coaches cease to exist, organisations may crumble under their inertia in 5 years and the ones left will be great places to work" ... from a Behavioural Economics standpoint, the second option seems better.

Being a SLICE fundamentalist, I decided to run this hypothesis and began my experiment on 3rd June 2019, the day after I finished my last batch of ICAgile's Agile Coaching training. At the time of submitting this proposal, it hasn't been very long since I started the experiment, and it hasn't been easy to deliberately take a step back from coaching interventions. The observations have been interesting (if not amazing) so far and this is my experience report that I wish to share during Agile India 2020.

My plan is to run a set of experiments until 31st December 2019 and then decide my way ahead. I mention below the observations so far that I wish to share in my talk but there may be other experiments that I'll share if provided a platform at Agile India 2020.

One of the key reasons for embracing Scrum is faster feedback which helps improve the perceived quality of a software product. And every team is focused towards delivering quality, no one wakes up in the morning with an idea to introduce defects, we naturally ideate to solve problems. Unknowingly though, anti-patterns always creep in and identifying an anti-pattern is extremely difficult especially when you are a part of the anti-pattern.

In this 45 min presentation, I discuss about the accountability of quality and how it's not negotiable even if Project Management principles tell us otherwise. I share stories from my past experience, and from organisations ranging from GM to Mumbai Dabbawalas that have embraced the "Quality is not Negotiable" principle and seen the difference.

I present the context of defect severity and how these may create an illusion of quality; how accountability of a single person (e.g.: Product Owner) may result in a "Lack of Commitment" dysfunction; and how cost is not really proportional to quality especially when it comes to delivering virtual products and services related to it.

I end the talk with practices that help build in quality and in the interest of an interactive session, many of these scenarios turn out to be debates since the context may differ; these debates are always good ways to solve problems (moving away from "Fear of Conflict").

This talk is based on my article titled The Entropic Future of Software Quality

One of the key reasons for embracing agility is faster feedback which helps improve the perceived quality of a software product. And every team is focused towards delivering quality, no one wakes up in the morning with an idea to introduce defects, we naturally ideate to solve problems. Unknowingly though, dysfunctions always creep in and identifying a dysfunction is extremely difficult especially when you are a part of the dysfunction.

In this 45 min talk, I discuss about the importance of quality and how it's no longer negotiable even if Project Management principles tell us otherwise. I share stories from my past experience, and from organisations ranging from GM to Mumbai Dabbawalas that have embraced the "Quality is not Negotiable" principle and seen the difference.

I present the context of defect severity and how these may create an illusion of quality; how accountability of a single person (e.g.: Product Owner) may result in a "Lack of Commitment" dysfunction; and how cost is not really proportional to quality especially when it comes to delivering virtual products and services related to it.

I end the talk with practices that help build in quality and in the interest of an interactive session, many of these scenarios turn out to be debates since the context may differ; these debates are always good ways to solve problems (moving away from "Fear of Conflict").

This talk is based on my article titled The Entropic Future of Software Quality

Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuous improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

• S hare: Share an area of improvement
• L earn: Explore the area for ways of improvement
• I mplement: Search & apply the learning to identify the success factors
• C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
• E xpansion: Grow, Seed, and Split in order to explore new venues for success

In this talk, I create an environment that inculcates an experimentation mindset and utilise the SLICE framework to drive the exploration.

Objective

Objective of this workshop is to understand depth and meaning of scrum
master role, how to deal with complex real life challenges as a scrum
master and how to build roadmap to become a great scrum master.

"Why are you doing this to me?" - said the weeping Product Owner while shackled around the chains of a virtual conference where the hysteria of a development team built a mountain of expectations that crumpled on the shoulders of an individual who merely wished for happiness. Isn't this real?

The intention of this talk is not to demean the profession of Product Ownership and I'm definitely not saying that killing them is a solution; in fact, the opposite. I wish to highlight the dysfunctions around this (cool) profession and make ourselves realise how development teams may hijack the Product Owner's responsibilities which may end up killing the credibility and the value chain driven by product ownership.

This talk is based on this article: https://www.linkedin.com/pulse/killing-thy-product-owner-vishal-prasad

One of the most widely used Scrum anti-patterns is the infamous Sprint Zero. This iteration is used by many teams across the globe as a period for homework activities before kicking off a project. Activities may typically include backlog refinement with the product owner, setting up development environments, reading deployment pipelines, applying logging frameworks, etc.

It has been mentioned multiple times by the innovators of the Scrum Guide that it shouldn't take more than a day to begin a project, alas as the Scrum Guide mentions, Scrum is simple to understand, difficult to master; and the difficulty increases exponentially as we scale. So here's a workshop to master a one-day project kick-off using an extension of the white elephant exercise which I like to call - the Grand White Elephant for scaled teams.

Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuos improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

• S hare: Share an area of improvement
• L earn: Explore the area for ways of improvement
• I mplement: Search & apply the learning to identify the success factors
• C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
• E xpansion: Grow, Seed, and Split in order to explore new venues for success

In this workshop, I create an environment that inculcates an experimentation mindset and utilize the SLICE framework to drive the exploration.

This topic is not meant to demean the profession of Product Ownership and doesn't mean that the Product Owner is not essential so killing them would solve the problem; rather it highlights the amount of dependencies a development team may end up building around the Product Owner that may end up killing the credibility and value chain driven by product ownership.

Keeping aside the fact that organisations today recruit Scrum Masters and Product Owners as designations instead of scrum roles, the role of product ownership has been misunderstood as a one person job, which kills the entire purpose of being a Product Owner - voice of the customer to maximise ROI. PO doesn't own the product alone and definitely doesn't own the implementation details. Enough said, this scrum role needs a deeper understanding. Then again, who performs this role in XP or Kanban or SAFe or a no framework setup?

In this session, I execute 3 iterations to highlight the team's dysfunctions, and apply practices a team can perform so a Product Owner can function much better and improve the credibility of this role. It's pretty quick and enlightenting; all hands-on, no PPT.

TBD

To be added

Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuos improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

• S hare: Share an area of improvement
• L earn: Explore the area for ways of improvement
• I mplement: Search & apply the learning to identify the success factors
• C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
• E xpansion: Grow, Seed, and Split in order to explore new venues for success

In this workshop, I create an environment that inculcates an experimentation mindset and utilize the SLICE framework to drive the exploration.

Technical debt is a very common phenomenon; in fact it occurs with virtually every line of code whether you want it or not. Although unoptimized coding due to the rush presented by management pressure may be one of the major reasons for technical debt, it occurs in various flavors based on the nature of execution. Sometimes, even the best written code may run into debt by introducing a minimalistic change in the business definitions, e.g.: a variable name that makes no sense anymore.

This debt cause and effect is exponentiated when scaled teams come into play. In many cases these teams are distributed and an optimized code for one team may become a debt for another. These debt dependencies between teams is what creates the "Valley of Debt". Unfortunately these cannot be avoided but good engineering practices coupled with lean principles may keep them confined for long enough in order to push the validity of software applications.

Sooner or later, the cost of change will outweigh the benefit of an application and turn it into legacy; the challenge is to keep it as far as possible by slowing down the fall into the valley of debt. In this (non-PPT) interactive workshop, we will witness first hand how debts are introduced and how these can be confined by utilizing good engineering practices coupled with lean principles.

This world has seen many generations. The first generation was when Software Engineering had two major stages - Analysis & Coding. The second generation expanded this to hours of exhaustive Manual Testing. The third generation of smart people took the next step towards Automated Testing. But should the smartness stop there?

Introducing the next generation of smart testing where the goodness of Exploratory Testing meets the ferociousness of Automated Testing. That's where we achieve Testing Nirvana!

Purpose: To demonstrate how productivity can improve by engaging testers from the very first day of a sprint

Questions to ask yourself:

1. Does your team receive all the features at the end of the sprint for testing?
2. Do you have the concept of code freeze in your project?
3. Does your sprint usually spill over because testing is not completed?
4. Do you demonstrate features to your stakeholders that have not been tested?
5. and many more testing paradox...

If your answer to any of the above questions is YES, then it's time to fix these problems.

In this session, not only will I demonstrate how you can engage your testing team from the very first day in order to start (that's right, start) testing your application, but also help you achieve this by means of some simple exercises.

Consider an agile utopia executing scrum for software development. How would you feel if your biggest strength of receiving early feedback from your end-users turns out to be your Achilles heel? Recently I faced this dilemma where my end-users unfortunately were a group of introvert individuals. This led to Monger project’s MVP almost declared as a failure since it did not fulfill the end-user’s requirements. 

Many a times, projects transform their delivery mechanism from traditional models to agile with a myth that agile is a recipe for success. In reality many projects fail since agile is not well understood by the teams. A few times (like in this case) the agile process falters not due to incorrect implementation but due to incorrect participants responsible to execute a part of the process.

Experience with me what happens when your end-users falter your feedback loop just because of the nature of individuals. If you’ve ever been a part of a group (or may be in the future) where your end-users are introverts, learn from this experience report how we overcame this problem on the Monger project by strengthening our anemic reviews. At the same time, if you as a participant have been there and done that, I would love to hear about it. 

Consider an agile utopia executing a lean build-measure-feedback loop for software development. How would you feel if your biggest strength of receiving early feedback from your end-users turns out to be your Achilles heel? Recently I faced this dilemma where my end-users unfortunately were a group of introvert individuals. This led to Monger project’s MVP almost declared as a failure since it did not fulfill the end-user’s requirements. 

Many a times, projects transform their delivery mechanism from traditional models to agile with a myth that agile is a recipe for success. In reality many projects fail since agile is not well understood by the teams. A few times (like in this case) the agile process falters not due to incorrect implementation but due to incorrect participants responsible to execute a part of the process.

Experience with me what happens when your end-users falter your feedback loop just because of the nature of individuals. If you’ve ever been a part of a group (or may be in the future) where your end-users are introverts, learn from this experience report how we overcame this problem on the Monger project by strengthening our anemic reviews. At the same time, if you as a participant have been there and done that, I would love to hear about it.