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.

How many deliverables should we commit to our customers in, say, the next two weeks? An intriguing question asked by many Agile teams at the beginning of every iteration. The answer to this question depends largely on the team's thinking, philosophy, and skills -- which unfortunately cannot be measured. Then how do we forecast the deliverables?

How about a mathematical formula that provides an unbiased control based on the historical achievements of the team, which can be used for prediction? That's exactly what focus factor does.