What if we narrate 3 anecdotes about unconventional means to create happy engineers?

Story #1 - How a product owner made the engineers happy by articulating their customers' extra sleep due to the team's work?

Story #2 - How did a 'rewards committee'  come up with a reward for a star engineer, with a budget of 0 INR?

Story #3 - How did a 'product team' take on the adventure of killing the mutant invaders using JavaScript while saving money for the organization?

Agility, we hear, is all about responding to change.   Evidence-Based Management aka the hypothesis driven way of looking at the business world, is one way to build muscles in order to respond to changes gracefully.

This experiential role-play-driven workshop enables leaders to create a self-adapting framework to make 'responding to change' a natural exercise, rather than the stressful showdown when the business is challenged.

We will present our experience with hypotheses as a mental tool for agility and also facilitate a workshop where the audience will role-play to be a leader who tackles various problems at hand using hypotheses.

1. I understand DevOps and XP theoretically but haven't done anything hands-on. I would like to experience how it is like in practice.
2. I know how to write code but I want to learn how to craft software with excellence.
3. I do not know how to fit the testing in 2 week sprint cycle.
4. My product has unmanageable number of bugs and I have been given the task of managing the quality. I need some practical advice on this.

If you relate to any of the above situations, this half-day workshop is for you. In this workshop, we will take you through hands-on learning of XP and DevOps practices.

Are you interested in learning how development team members can change their working style to be agile? Are you looking to learn how to improve developer engagement? Do you want to watch the benefits of agile technical practices in action? If yes, this hands-on demo is for you.

This interactive demo is designed as a role-play by the facilitators and the members of the audience. The facilitators will engage in a dramatized demo of common technical agility practices, sometimes involving the audience, so that the audience can themselves see their benefits in action.

Join this demo for living through the phases of attaining technical agility.

Have you ever wondered about the mechanics of how human beings learn? Does your job involve teaching something to others? Or, do you want to teach a new skill to your child at home? If you are looking to add another tool to your teaching toolkit, particularly if you are an Agile Trainer, then the Pyramid of Humble Mastery is for you.

In this interactive workshop, we introduce the Pyramid of Humble Mastery, a model that we have used to teach concepts like Agility, DevOps, etc to audiences of various maturity. This workshop will take a conversational tone filled with hands-on activities and ample time for answering questions from the audience.

The audience will leave this workshop with hands-on experience of how to teach any new field meaningfully using this model.

Have you ever wondered about the meaning of 'Happiness at Work'? Does everyone define them the same way? If not, how can an executive work towards improving the happiness of his employees? If you have these questions, this session is for you.

With the increase in population that separates ‘work’ from ‘life’, as if work is the 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 Business Agility keeps us happy in the true sense.

The two studies that this session will discuss 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 scenario-based questions, thereby bringing out personal examples that they can relate to.

Most of the organizations focus on adherence to frameworks, Agile practices, restructuring of teams & roles as part of Agile Transformation with minimal focus on cultural transformation. Even the very few organizations that do focus on Cultural transformation focus primarily on practices and policies than on mindset, values and purpose.

Every organization that is looking to transform has an existing culture that is driven by its core values, beliefs and undefined practices. This defines how people operate on a day to day basis, how the transformation exercise is kicked off and the way it evolves. However, for the transformation to be successful, it is imperative that the transformation team Identifies & outlines the existing culture and is able to define the cultural aspects that need to change for it to be an Agile Organization. This needs clear understanding of various aspects of organizational culture, leadership agility levels, what can be done to identify the current culture and what is needed to be able to define the target state.

The intent of this workshop (No PPT) is to get the audience to understand the importance of cultural transformation, the aspects that one needs to focus on and also the means needed to define the organizational culture than it defining the individual.

The hands-on interactive session will introduce the audience to the Cultural Iceberg, Language, Habits and Mindset template to be able to clearly distinguish the need for focusing on Organizational culture, Leadership Agility Levels and the active involvement of the C-suite and Senior Leadership in defining the culture needed in the new ways of working.

Have you ever wondered about the meaning of 'Happiness at Work'? Does everyone define them the same way? If not, how can an executive work towards improving the happiness of his employees? If you have these questions, this session is for you.

With the increase in population that separates ‘work’ from ‘life’, as if work is the 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 Business Agility keeps us happy in the true sense.

The two studies that this session will discuss 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 scenario-based questions, thereby bringing out personal examples that they can relate to.

Have ever wondered how to test your test cases? Do you wonder if your test coverage report is giving the correct numbers?

If you’re concerned about the quality of your test data and test cases, then this is the subject for you.

Mutation test is the way to evaluate your test data quality and the test cases. Get into this session to get introduced to the concept of Mutation testing and to see some cool demos.

Do you feel that communication can be improved among Biz, Dev and Ops?

Do you know that Behavior Driven Development(BDD) can help you there?

Do you know what is the cost of putting BDD into practice?

Join us in this interactive workshop on how to get benefits of BDD with (almost) zero dollar investment.

Learn some simple ways on how you can implement BDD on your own, no matter what your role is.

With the arrival of distributed applications that run on Blockchain, it is essential to rethink some of the basic aspects of DevOps. Few things that we take for granted in DevOps area are either irrelevant, impossible or too costly for blockchain applications. Join us to explore the changes that the blockchain apps bring to the DevOps arena, using a hands-on demo of a sample blockchain app.

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.