"You can’t legislate against failure, focus on fast detection and response."

You can think this as a fairy tale story -

As once upon a time, in theory, if everything works perfectly, we have a plan to survive the disasters we thought of in advance.

But big Question is How Did That Work Out ?

We are here to answer that Big question with our session.

While it is possible to sit down and anticipate some of the issues you can expect when a system fails it, knowing what actually happens is another thing.

This really depends on what your tolerances for failure are and based on the likelihood of them happening.

The result of this is you are forced to design and build highly fault tolerant systems and to withstand massive outages with minimal downtime.

The prevailing wisdom is that you will see failures in production; the only question is whether you'll be surprised by them or inflict them intentionally to test system resilience and learn from the experience. The latter approach is chaos engineering.

The important aspect of Chaos Engineering is Chaos Testing.

Historically, the emphasis has always been on mean time to failure (MTTF); working hard to extend the time between system failures, with little emphasis on how fast a failure could be corrected.

In today's world, the emphasis needs to shift to mean time to recover (MTTR), minimizing the time it takes to recover from a failure.

At a high level, chaotic testing is simply creating the capability to continuously, but randomly, cause failures in your production system. This practice is meant to test the resiliency of the systems and the environment, as well as determine MTTR.

Adopting chaotic testing will help improve your MTTR, improve organizational confidence in the resiliency of your production environment, and it will also keep you out of tomorrow's headlines.

In an Agile world,we are being asked to move faster—reducing the length of time to delivery while still continuing to improve the quality. At the same time, we are faced with increased pressure to reduce testing costs. The main aim of Shifting left is ‘Early Defect Detection to Defect Prevention’.

Bugs are cheaper when caught young. Being a testing professional during start of my career where i have seen the agile transformation from ground zero. I have experienced all what a tester can face usually in start of a agile way of working.

Most difficult phase is shift from defect identification or detection mode towards a more collaborative approach of defect prevention.

Why a tester was no more quality police and he/she is not the sole responsible person for quality but it was whole team. Development teams need to focus on quality from the beginning, instead of waiting for errors & bugs to be discovered late in the game.

These learning and many more in my early career helped me when I started coaching agile teams for delivering better quality product. In recent time where I am leading a transformation , one of the major ask was to break the boundaries and silos between development and system testing teams. This topic is close to my heart because i have practiced , performed and tried to perfect time and again.

I want to share How “Shift-Left” Testing Can Help Your Product Quality? What it means to testing community, with vastly different skill sets, are getting involved in the testing process. More specifically, it means that development teams are being incorporated into the testing cycle earlier than ever before.

\

When we are on the floor & wearing the coaching hat - we are dealing with 3 things -

1. Ourself (Coach himself)
2. Person (Coachee)
3. Problem

According to Chad W. Hall, there are also three levels of coaching which he describes in Coach The Person Not The Problem.

1. Beginner: Coach the Problem
2. Better: Coach the Problem through the Person
3. Transformational: Coach the Person for Internal Change

It is very important to understand the 3 levels of coaching. Many of us we operate at level 1.

We will share some recent practical & experential examples/learnings which emphasizes more on coaching at level 2 & 3.

Note - Inspired from the book "Coach the Person Not the Problem: A Simple Guide to Coaching for Transformation - By Chad Hall"

When we are on the floor & wearing the coaching hat - we are dealing with 3 things -

1. Ourself (Coach himself)
2. Person (Coachee)
3. Problem

According to Chad W. Hall, there are also three levels of coaching which he describes in Coach The Person Not The Problem.

1. Beginner: Coach the Problem
2. Better: Coach the Problem through the Person
3. Transformational: Coach the Person for Internal Change

It is very important to understand the 3 levels of coaching. Many of us we operate at level 1.

We will share some recent practical & experential examples/learnings which emphasizes more on coaching at level 2 & 3.

Note - Inspired from the book "Coach the Person Not the Problem: A Simple Guide to Coaching for Transformation - By Chad Hall"

Scrum is a practical framework to build products, provided you identify, in advance, what to build. However, even after a successful product discovery phase, you may struggle to implement the right way if your product backlog is not up to the job. Garbage in, garbage out — as the saying goes.
Managing the product backlog is a full-time and continuous evolution.

In this session, we will share simple techniques that can help change what can be an overwhelming and time-consuming process, to an interactive, iterative process that effectively engages team members, customers, and stakeholders. It will teach you how to develop solid techniques to help you build, prioritize, and maintain your product backlog.

A QA Perspective on Agility and Scrum.Focus is mainly on QA role in Scrum,Challenges & Implementation of correct QA process in Scrum.

This case study is to break the shackles of misconception or a myth that agile development places less emphasis on testing.
Some QA professionals believe that the quality of software is compromised due to the shortened periods allotted for testing, which results in releasing software that has been only partially tested.
Some think that with complete automation and continuous integration, the software testing job will become obsolete.
Contrary to the synchronous activities of a traditional Waterfall project, Scrum expects development activities to be performed in the order they are needed – i.e. asynchronously.
This break from tradition raises a common question by many of the clients, developers, and business stakeholders new to Agile – “How can testing professionals engage effectively during a sprint before anything has been built?”
This article focuses on explaining how the QA role performs agile testing and the place of importance they hold on a Scrum team.
Many think that maybe testers are not at all required and are a liability in the Agile process.

This study was an attempt to find the truth and myth.

This is an effort to look into agility and scrum from a perspective of QA. Which is although not a defined but very integral part of an agile team. I have tried to touch upon many bases as QA roles, Process, Challenges and benefits realized. How the different stages of QA contribute to Continuous Integration and Development and enables a Quality product delivery. I have a strong
belief of learning with Sharing.

This Study was executed based on survey as well contains some relevant questionnaire based on the topic. It was not limited to following questionnaire.

1. Is the team cross functional and independent to deliver functional software (story) within a sprint?
2. Do you have a setup to handle continuous integration and delivery to maintain the pace of delivery?
3. Are you using Automation to optimize effort and to improve product quality?
4. Is the deliverable at the end of the sprint / iteration ready to be shipped? (Is there a separate testing phase or deliverable from each sprint is ready to Ship?)
5. Do you adapt techniques like Mocking Objects, Simulators, and Stubs etc. to take care of dependencies within Sprint instead of waiting for delivery from other team?

6. In case of distributed team, are there a handshake / stand-up meeting daily with business partner team located remotely?
7. Are the QA activities part of DOD and are there enough time for it?
8. What is the ratio of QA to Programmers in Development team?

For all the above survey questions response, recommendation and suggestions were requested.
Based on the same model of above questionnaire set this study accumulated some real time data which helped to understand derive data on QA Practices, roles and challenges in Agile organization.
The study further helps to understand the general QA practise being followed in agile teams and tester’s mind to understand how Scrum enables complex development practices such as CI and CD, and how it influences day-to-day approaches to software development.
With this case study I would like to share with fellow learners how QA/ tester as individual and practice plays a very important role for successful delivery of Software development and what are the challenges involved.

Scrum is a practical framework to build products, provided you identified in advance what to build. However, even after a successful product discovery phase, you may struggle to make the right thing in the right way if your product backlog is not up to the job. Garbage in, garbage out — as the saying goes.

Managing the product backlog is a full-time and continuous evolution. In this session, we will share Simple techniques that can help change what can be an overwhelming, time-consuming process to an interactive, iterative process that effectively engages team members, customers, and stakeholders. It is essential, therefore, to learn solid techniques to help you build, prioritize, and maintain your product backlog.

Retrospective is the heart of scrum and agile world. We need to ensure this heart is well connected to other parts and functioning well. Getting the right amount of inputs and making sure with the right outcomes. This workshop will be an eye opener to understand anti patterns of retrospective. It will be more of a hands-on exercise for all the attendees based on our experiments which we have conducted got benefited. Will help to practice an effective retrospective which enables the team to seize opportunities to improve. Retrospectives can become monotonous and boring over time and so they become ineffective. We need to bring something new, fun, or exciting to the retrospective to make it lively.

This workshop will lead a way as a food for thought for scrum practitioners. Why it is important to ensure that each team member is comfortable participating and sharing thoughts and ideas requires that the Retrospective be conducted with an atmosphere of respect, honesty and positivity. Retro facilitator who contributes structure and process to a Retrospective to help the Scrum Team identify and bring about an outcome that is consistent with the Team’s objectives.

Will also cover the aspect as how a Retrospective lacking a Facilitator will suffer problems similar to a team-based sporting event lacking a referee. Retrospective should be facilitated in a healthy and fun way, team level engagement should be taken on priority. Retro outcome apart from the action items team should look forward to participate and leave a mark.

Successful retrospection responsibility who ensure, is it team or scrum master or both? Together teams need to think outside the box when approaching Sprint Retrospectives and appreciate that these short gatherings need not to be done only by using the usual techniques or methods. Instead they can bring their own ingenuity, knowledge, and experiences to the table to create games or to start meaningful discussions that the team drives.

Product quality plays a key strategic role in any organization success. Organizations have tried and tested many tools, techniques, methodologies or mechanisms to achieve best possible quality while trying to meet time to market demands. Agile methods have gained prominent attention of CXO as a strategic piece for IT and Business alignment. Many organizations have embraced agile journey in recent years and have reported noticeable improvement in product quality, customer satisfaction, early value delivery (Time to market) and increased people engagement at workplace.

One of the magical factor driving product quality improvement in Agile Scrum is Definition of Done( DoD). A well thought and implemented DoD keeping Tech Debt as a reference would result in significant improvement of Product Quality.
This paper provides summary of our experience of implementation of DoD, Tech Debt reduction strategy and magnificent results we observed in an enterprise level large complex legacy system.

However exhaustive and meticulous your current employee appraisal process is, chances are you aren't pleased with the outcome. The primary objective of a performance appraisal is performance improvement, starting with the individual and rolling up to the organizational level. But an individual who doesn't fare well in an appraisal feels demotivated, defeating the purpose of the exercise.

Agile owes its success and failure to its team.

A lot been discussed on different agile groups related to performing the appraisal of team members when success / failure belongs to team.

This is an Attempt to provide solution to appraising scrum team members remaining in agile framework and philosophy.

We would be discussing The Challenges of current appraising process along with the Challenges brought up with adopting agile process.

To address these challenges we would be sharing 'The proposed solution' and it's alignment with agile philosophy.