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.