Did you know that the position of the build monitor affects the speed at which build failures are fixed? Did you know that using some colors in your build monitor can render it useless to 1 in 9 men? Do you wish to know when to use the Red-Amber-Green color scheme and when to avoid it, in your information radiators? If these discussions interest you, then this session is for you.

When teams deliver increments of working software using a continuous delivery pipeline, it becomes important to close the feedback loop by letting the team members know as soon as possible when something fails. This interactive session aims to create discussions about the mechanism of human cognition and response and how taking some extra care in designing information radiators can optimize the human response time to anything wrong happening in the delivery pipeline.

Disclaimer: This Talk Proposal has been submitted for participation purposes only and is not intended to serve as an advice of any nature whatsoever. Opinions are my own and not my employer's.

Does your organization frown upon “Build Breakers”? Does your team spend a lot of time fixing integration issues in CI? Do you see a lot of “Who broke the build now?” emails? Do your team members hesitate to commit their code for the fear of causing a build failure?

If you wish to know what you can do to make the situation better, this session is for you.

Continuous Integration is a powerful way to identify and eliminate certain risks, particularly when multiple teams are rallying towards a planned release. Even if you are not working on a planned release, Continuous Integration will help you to cut-out a release sooner than you would if you did not have CI.

When organizations or teams start adopting Continuous Integration for the first time, they develop an untold habit to chastise the build breaker, whenever a build breaks. Most of the time, the reprimanded build breaker is a person and not a thing, a machine or a process

• Do 'Blame Game Politics' rule your workplace?
• Are you frustrated of retrospective meetings that result in zero outcomes due to endless debates on who is to take the blame?  
• Does the "Blame" monster haunt you every time you try to do something new?  
• Are you afraid of taking risks for the fear of being labelled the 'wrong' one?  
• And, above all, do you wish to tackle the blame game monster? 

If yes, then this session is for you.  This session introduces a toolkit to free oneself and others from the biases, based on research studies in the field of Social Psychology.  The toolkit provides one an 'objective' view of the situation at hand to decide on further actions rather than debating on who is wrong.

This session introduces common biases like 'Confirmation Bias' and the 'Fundamental Attribution Error', which every human being falls prey to.  The attendees will also be performing a guided team activity that helps them practice the Covariation Model to zero-in to the real root cause of any problem.

With the increase in population that separates ‘work’ from ‘life’, as if work is absence of life, it becomes increasingly important to study about what happiness means to people at work, so that they can be made to feel alive in their offices too. This session is aimed at introducing two interesting research studies that aimed to do just that. Also, this session helps people understand if agility keeps us happy in the true sense.

The two studies that this session will discuss about are as follows:

1. Richard M. Ryan et al’s Self Determination Theory – led to a book Drive by Dan Pink
2. Mihaly’s Measurement of Flow in Everyday’s life – led to book Flow by Mihaly himself

This session does not just explain these two research works but also will find the commonalities between these and will engage the audience with discussions using leading questions, thereby bringing out personal examples that they can relate to.

"Congratulations, Raj! Your first commit has passed the Continuous Integration Gate!" - The announcement from a digital speaker fills the team's work space. The entire team starts cheering for Raj immediately. Raj displays a surprised look and delivers a shy smile.  The day has been made for Raj, whose first AND 'green' commit just went in after days of learning and on-boarding.

Want to implement this in your start-up or enterprise? Are you worried about the cost of this system?

All it takes is just a tiny computer called Raspberry Pi, that can fit in your hand and most importantly, whose cost can fit your wallet!

The cost can be as low as 40$ per team.

Join this session to explore variety of human-touches that you can create for your team to keep the team engaged and motivated.

This session explores ways of integrating Raspberry Pi with various Agile tools to create 'Aha!' moments for the team.

Want to understand how NOT to do Pair programming? Attend this session to see some funny examples of the same.

Pair Programming is to programming in the same way as Object Oriented Programming is to... well.. eh.. programming!  Any agile startup which does not encourage Pair programming is referred to as by "stone age" startups by developer groups.  And, the fact is that these developer groups are not fringe groups.

While there are a lot of guides to tell a beginner how to do pair programming, it is very easy to get a wrong understanding of Pair Programming.  This session helps you understand nuances of pair programming by telling how NOT to do it.

Audience will be presented situations (a comic strip, a code block, a conversation, etc) and will be asked to spot what is wrong with each of those situations.

The summary will present ten things(that the audience found out from situations) that are not to be done during Pair programming.

Gone are the days where developer was responsible for just writing clean code. Traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product. As a Developer 2.0, the developer performs all of the following roles. 

1. Coder 

2. Devil's advocate 

3. Code Reviewer 

A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.

Can we bring phenomenal changes by doing small changes in the mindset of developers in the organization?

Gone are the days where the developer was responsible for just writing clean code. The traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product.

As a Developer 2.0, the developer performs all of the following roles. 

1. Coder 

2. Devil's advocate 

3. Code Reviewer 

A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.

The audience will work through some activities for two sprints and see the difference for themselves.

Gone are the days where developer was responsible for just writing clean code. Traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product. As a Developer 2.0, the developer performs all of the following roles. 

1. Coder 

2. Devil's advocate 

3. Code Reviewer 

A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.

Do you fancy playing the first Scrum Master of a startup?

Do you want to live the challenges faced by the first Scrum Master of a startup?  Do you feel that your organization is dramatically different from the 'ideal' organizations, which the Agile workshops project as a basic requirement for doing Agile development?  Do you wish to deliver predictable results while your management is on-the-way to make your organization 'Agile-ready'?  This tutorial is just what you want.

In this tutorial, you will experience the life of a first Scrum Master of a twenty member startup, which has expansion plans.  Each of the audience will put themselves in the Scrum Master's shoes and try to solve the challenges posed by the ever-changing environment, while the company's management is putting its best efforts to make the organization 'Agile-ready'.  In this interactive tutorial, a gripping story-line will drag you into the world of uncertainties where you would be challenged to take life-changing decisions regarding your product team's daily work.

Even if you are not in a startup, this tutorial would benefit you because everyone still comes across ad-hoc situations which go against the ideal expectations of Agile world.

Do you fancy playing the first Scrum Master of a startup?

Do you want to live the challenges faced by the first Scrum Master of a startup?  Do you feel that your organization is dramatically different from the 'ideal' organizations, which the Agile workshops project as a basic requirement for doing Agile development?  Do you wish to deliver predictable results while your management is on-the-way to make your organization 'Agile-ready'?  This tutorial is just what you want.

In this tutorial, you will experience the life of a first Scrum Master of a twenty member startup, which has expansion plans.  Each of the audience will put themselves in the Scrum Master's shoes and try to solve the challenges posed by the ever-changing environment, while the company's management is putting its best efforts to make the organization 'Agile-ready'.  In this interactive tutorial, a gripping story-line will drag you into the world of uncertainties where you would be challenged to take life-changing decisions regarding your product team's daily work.

Even if you are not in a startup, this tutorial would benefit you because everyone still comes across ad-hoc situations which go against the ideal expectations of Agile world.