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.

So you're an adult (may be a teenager) working for an organization that is dedicated to provide products or services that help your customers earn money. That's cool, welcome to adulthood.

Now stop and think, what do you miss the most from your childhood?

What if I tell you that you can re-live your childhood at your workplace and still help your customers to earn money? Would you be interested to be a kid @ heart and play games as a part of your serious business in-order to get the job done?

In this session, I will demonstrate 3 games (which you will play) that can help you tackle common workplace chores:

1. Out-Perform (a game to manage your goals and performance management)
2. 7-11 (a game to manage your prioritization problems with a large group)
3. Dice Roll (a game to manage critical decision making)

And of course, in our society, change is difficult. Convincing your organization (or a part of it) that games are a good way of solving problems is easier said than done. I will share the obstacles that I've faced and some tips & tricks (that's right, you need to trick them sometimes) in order to introduce happiness @ your workplace.

This will be a hands-on fun-filled workshop. No boring presentation slides here!

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.