Submission Guideline – 2017


The final deadline to submit a speaking proposal for XP Conference India is September 24, 2017. We begin building the schedule as great topics come in, submitting your proposal early may give you a better chance of being chosen.


At the conference we would like to see demonstrations and talks of technical flavors. We have done away this year with the hard and fast rule of having speakers present only around a set of specific themes. And instead we encourage and invite any promising topic related to agile processes and software development practices and tools of “Moving from Cyclic to Continuous Value Delivery.” Just to get you thinking, your topics could be around:

  • Extreme Programming
  • DevOps
  • Continuous Integration
  • Continuous Delivery
  • Clean Code
  • Agile Testing Practices
  • Unit testing for various Systems/Frameworks
  • Refactoring
  • Simple Design Techniques
  • Tools and Apps and Techniques

You can propose any other practice you could be interested in. Topics that include a keyboard based demonstrations will be preferred. Only talks are welcome too but will be less preferred.


Our feedback from attendees in last year’s XP Conference India indicates high interest in interactive sessions and workshops and talks that help them learn something new. Our intent this year will be hence to bring more such sessions that deliver the best learning experience possible for attendees. Our blog what does the program team look for in a submission gives insights to making a stellar submission.


The answer is anyone with the depth of experience and technical competency necessary to deliver cutting edge presentations and answer detailed attendee questions about the presentation topic.

When submitting a session proposal please do indicate your experience and interest areas.


A session could be of 30, 45 or of 60 minutes or for half/full for Workshops depending upon the nature and content of a topic. Throughout the two days there will be an open jam area for informal learning where you can announce topics on the spot and can share with participants. Speakers must arrive at the designated location for their session at least 15 minutes prior to the scheduled session time in order to setup and prepare prior to the scheduled start time.

Slides MUST include the XP Conference India logo in the footer. Please do plan for time to share your slides at least two weeks before the event to provision advance review of slides and incorporating edits upon request.


XP Conference India is interested in sessions with informative, thought provoking and cutting edge content that keeps the audience engaged and interested. Speaking at XP Conference India is an excellent opportunity to build awareness and credibility for you and your organization. Delivering a hard sell or product pitch in a conference session is frowned upon and highly discouraged for the benefit of our attendees and you, the speaker.


This year we are offering ask the speaker gatherings on the exhibition floor. Part of speaking at XP Conference India will include making yourself available for one of these gatherings, an additional 1 hour time commitment is highly recommended


Sessions may be video and/or audio recorded for use following the show. Speakers agree by submitting and delivering a presentation to allow and assign non-exclusive rights to XP Conference India  to capture, distribute, reproduce, and/or make available (including but not limited to paper or electronic format) their presentations without license or liability


Speakers are encouraged, for mutual benefit and as reasonably appropriate, to promote XP Conference India , and specifically their session, through available communication channels. This includes but is not limited to company blog, Twitter , LinkedIn, FaceBook and company newsletters.

Speakers have the option to provide one blog post of 400 – 500 words for the purpose of promoting their session on the XP Conference blog. The blog post may contain a brief speaker bio of 50 words or less.


You as a speaker are allowed to introduce a co-speaker/presenter for your session. You must indicate the same in your submission along with a bio on her/him. Speaker substitutions are generally not a great idea and hence not allowed. XP Conference India reserves the right to refuse to accept an alternative speaker and pursue other interested parties to present the topic at its sole discretion.


XP Conference India strives to interesting and relevant session content at each XP Conference India event. You are encouraged to keep reuse of old content or previous session topics to minimum. If you propose a topic that you had presented earlier, please ensure and indicate that the topic was well received and had created a buzz enough to repeat it.


The last date to make a speaking proposal for XP Conference India is September 24, 2017.

Intimation of selection will be made between October 1 and October 15, 2017

Reviews and Edits (if any) of content to happen after the intimation of selection

Go to Submission Form

Pairwise Testing in Agile World

This blog is by Puttajunjaiah Krishnamurthy who will be presenting along with Arun Srinivasan on their talk – Pairwise Testing in Agile World – at XP Conference India 2016. This post first appeared in Puttajunjaiah’s blog site

The fundamental challenge in testing any system is that the exhaustive testing is often impossible! This is owing to a large number of combinations of inputs to the system under test. The number grows exponentially high as the number of input parameters and the number of values each of those parameters can take increases. Take for example, the aircraft cockpit control system which has at least 100 switches and controls.


Even if each of these controls take 2 values (ON or OFF), it takes 2 ^ 100 = 1.2676506e+30 combinations to thoroughly test the system. That takes more than a lifetime for someone to test this system!! Not to forget the regression testing when things change. World is moving towards agile methodologies which means shorter release cycles. So quick test feedback on every build is absolutely necessary. Even with 100% automation of these test cases, it takes several days/months to give this feedback. So, what is the alternative?

The combinatorial techniques like Pairwise testing (also known as All Pairs) hold some promise. The intuition behind Pairwise technique is that some problems only occur as the result of an interaction between pairs of parameters/components. For e.g, a failure occurs if pressure < 10 & volume > 300 (2-way interaction).

The researchers Wallace and Kuhn at NIST (National Institute of Standards and Technology) have determined that 98% of the reported software defects in recalled medical devices could have been detected by testing all pairs of parameter settings.

An Example:

Consider a system that takes 3 input parameters. Each parameter takes 2 values.


Total no of combinations = 2^3 = 8


Pairwise Reductions by hand

We can get rid of test case T2, since all pairs of this combination are covered in at least one other combination other than itself. Hence it is redundant.

  • AC is covered in T1
  • CF is covered in T6
  • AF is covered in T4

With little bit of paperwork, you’ll be able to get rid of T3, T5 & T8.


So the reduced subset consists of just 4 test cases. Not a great reduction but the quantum of reduction is significant when there are more no of input parameters and their values.


Fortunately we don’t have to do this by hand. There are plenty of tools available in the market that can do this for us. Like PICT from Microsoft, TestCover etc.


1. Pairwise testing will not be effective if you choose the wrong input test data values 

2. Pairwise testing will not be effective if you don’t have a good enough oracle. We often assume defects can be immediately observed. In fact, there may be slow internal corruption occurring

3. High-use (including defaults) or high-risk combinations probably don’t get enough attention

4. We rarely understand the n-wise connectivity within programs we are testing, so it’s not clear that pairwise testing is an appropriate choice 39

Note: These dangers are not exclusive to pairwise testing. They affect all testing efforts

Perspective on Continuous Integration at Scale

This blog is by Hrishikesh Karekar (@hrishikarekar) and Vinaya Muralidharan (@vinaya1980) on their talk – Continuous Integration at Scale – at XP Conference India 2016. This post first appeared in Vinaya’s blog site

The word Enterprise conjures up images of big multi-million projects, thousands of people working together, distributed locations, complex products, multiple modules, projects impacting millions of users and mission-critical systems.

All of these are true for our environment.

This is the environment where we have successfully started our Continuous Integration journey and are enjoying great results.

When we embarked upon a journey to modernize and streamline the way we developed software, it was a daunting task. And the change was huge in all aspects – People, Technology, Processes.

But the results are very heartening. From being able to clone environments within minutes, to reducing build times from days to hours to the ability to deliver to customers frequently – we are experiencing the benefits every day today!

The road was not easy. Being a Service Delivery organization, and not Product Development, in itself posed a huge challenge. On top of that we were working with multiple products, multiple technologies and multiple specializations, with integration as our top issue to solve for years. Legacy source control and build systems limited our ability to learn from the industry.

We frequently worked on mega transformation projects for big Telcos. These were always multi-vendor environments demanding heavy upfront planning.

With the multi-product and super-specialization environment, our teams were component teams and not feature teams.

Against this backdrop, we undertook our Continuous Integration journey over 3 years ago.

Technology was our first stop – modernization was kicked off on several fronts – version control, builds, artefact management and test-automation framework. Our new technology stack (including Perforce, Maven, Nexus, Sonar, Jenkins) relied a lot on open source – we learnt from the collective knowledge of the industry!

Process – We supported the technology upgrade with lighter and more agile processes. We cut down on bureaucracy and focused instead on getting to working integrated software quickly and transparently.

People – People took center-stage in this transformation. Developers started being viewed as more than mere resources – we started acknowledging our craftsmen! The sphere of influence and impact of our developers increased and they were ably supported by new tools, processes and technology.

The change was huge and it wasn’t easy. We made a few missteps along the way but we are continuously learning and course-correcting.

Our developers had to learn new ways to code, our approach to metrics had to undergo a re-haul, collaboration between teams took on new significance and middle-management was recruited as an ally!

Many large enterprises may face similar challenges and we would love to share our experience with more people, to assist in our small way, in their transformation.

We have come a long way – however we have much longer to go.

We are already doing several proofs of concept in areas including security, deployment and automation.

The future holds many promises!

Come hear us share our experience at XP Conf India 2016