Agile India 2013 Conference hosted a total of 904 attendees over the 4 days. These attendees represented the following 195 different companies:

We had participants with 320 different roles at the conference:

Participants from 25 different countries participated in the conference:

They had the following Agile experience:

Number of Years of Experience

Lunch Menu

Dinner Menu

We have delegates registered from the following 122 companies:

• ABB IDC
• Aconex India Pvt LTd
• Aditi Technologies
• Alcatel Lucent India
• Alliance Global Services
• Allscripts India Pvt. Ltd
• Altair Engineering
• AppDev
• Aricent Technologies
• Aspire
• Atex
• Atlassian
• BA Continuum India Pvt Ltd (Bank of America)
• Bank of America
• BNP Paribas India Solutions Private Limited
• C-SAM Solutions Pvt. Ltd.
• CGI Inc
• Change Vision, Inc.
• Cisco Systems
• Clear2Pay
• Cognizant Technology Solutions India Pvt. Ltd
• Collabnet Software Pvt Ltd
• Comviva Technologies
• Crest Premedia
• CSC
• Curbralan
• Cybage Software Pvt. Ltd.
• Deinersoft, Inc.
• Dell International Services India Pvt. Ltd.
• Dev Bootcamp
• Digite Inc.
• Direction Software Solution
• DuraSoft
• eGain Communications
• eGain Communications Pvt. Ltd.
• Enteleki Technology Solutions
• Envestnet, India
• Ericsson
• Exelplus
• Exilesoft (Pvt) Ltd
• Fiberlink Software Pvt Ltd
• FICO India
• GE India Exports Pvt. Ltd
• GembaTech
• GSU
• HCL Technologies
• Crest Premedia
• Huawei Technologies
• IIT kanpur
• Independent Consultant
• IIT, Kanpur
• InfoQ & Thoughtworks
• InMobi
• InRhythm
• Institut Agile
• IntelliGrape Software Pvt. Ltd.
• Intergraph Consulting Pvt Ltd
• Iran Scrum
• IVY Comptech Pvt Ltd
• Fidelity Business Services India Pvt. Ltd
• John Deere India Pvt. Ltd.
• JP Morgan
• Khanyisa Real Systems
• MailOnline
• McAfee India Software Pvt Ltd
• McFadyen Solutios
• McKinsey & Company
• MEDIA iQ Digital
• MindTree Ltd
• Monsanto India IT
• Moolya Software Testing Pvt Ltd
• MSCI
• Multunus Software
• Napa Software Services India Pvt Ltd
• Navteq India Pvt. Ltd.
• Ness Technologies (India) Pvt Ltd
• NIIT Technologies Ltd
• Nokia Location & Commerce
• Novell
• Ostrya Labs
• Pitney Bowes Software
• Pondicherry University
• Rakuten Ichiba
• Reaktor
• Renatus Consultants
• Rotary International Infotech Pvt. Ltd.
• S.i. Systems
• Sabre Holdings
• SAP Labs India Pvt. Ltd
• Satyam
• Schneider Electric India
• SCIT
• SCRUMguides
• Sears IT & Management Services
• Self Employed
• Shop Smart Inc/BradsDeals.com
• Siemens Technology and Services Pvt. Ltd.
• Silver Stripe Software
• Simpthings
• Societe Generale
• SolutionsIQ
• Springer Science+Business Media
• SSN College of Engineering
• Still Point Software
• Stixis Technologies
• Support.com
• Symphony Teleca Corporation
• Synerzip Softech India Pvt. Ltd.
• Tata Consultancy Services
• TenXperts Technologies
• Tesco Hindustan Service Centre
• Thomson Reuters
• ThoughtObjectz LLC
• ThoughtWorks
• Transcendence Corporation
• UNOPS
• Velammal engineering college
• VMware India
• Waseda University
• Xicora
• Yahoo India Pvt Ltd
• Yellowtail Software

With the following 184 Unique Roles:

• Agile & IT Process Consultant
• Agile and Lean Coach
• Agile Coach
• Agile Coach and Lead Engineer
• Agile Coach/Scrum Master
• Agile Consultant & Coach
• Agile Head Coach
• Agile Project Manager
• Application Development Lead
• Architect
• Assistant Manager – Quality
• Assistant Professor
• Assistant Vice President
• Associate Professor
• Associate Project Manager
• Associate Software Developer
• AVP – Product Development
• AVP-Delivery
• BUSINESS ANALYST
• Business Manager
• CEO
• Chief Project Officer
• Chief Technical Lead
• Chief Technology Officer
• Co-Founder
• Co-Founder & Managing Director
• Co-Founder and CEO
• Coach
• Code Junkie
• Code Monkey
• CoE Lead – Agile SW engg and Web Technologies
• Commander
• Consultant
• Contributor Software Developer
• CTO
• Delivery Manager
• Delivery Manager (Pune)
• Development Engineer
• Development Manager
• Development Team Lead
• Director
• Director – Products
• Director ePlatform Development
• Director of Programme Management
• Director, Wireless Division
• Director-Quality
• Engg Manager
• Engineer 2
• Engineering – Director
• Engineering Best Practice Specialist
• Engineering Lead
• Engineering Manager
• Enterprise Agile Coach
• EVP & CTO
• Executive Manager
• Founder
• Free agent
• General Manager
• General Manager – Quality
• Group Manager
• Group Manager – Consulting
• Group Project Manager
• Head of Engineering
• Head of Project Management
• Head-IT Quality & Tools
• Help companies improve
• ICT Development Team Lead
• IT Architect
• Lead – Development and Testing
• Lead Analyst
• Lead Consultant
• Lead Engg
• Lead Engineer
• Lead Executive Quality
• Lead Software Developer
• Lead Software Engineer
• Lead Software QA Engineering
• Lead-Quality Assurance
• Lead-Software Engineer
• Leader Engineer
• Manager
• Manager Projects
• Manager Software Development
• Manager – Software Quality Engineering
• Manager, OPERATIONAL EXCELLENCE
• Managing Director
• MANAGING DIRECTOR & CHIEF EXECUTIVE OFFICER
• Manual QA Engineer
• Master Shifu
• Mentor-Coach
• Operations Manager
• Owner
• PhD Student
• Portfolio Manager
• Pre-Sales Consultant
• President
• Principal
• Principal Agile Coach
• Principal Agile Coach & Manager-Consulting
• Principal Architect
• Principal consultant
• Principal Software Engineer
• Prinicipal Software Engineer
• Product Development Manager
• Product Manager
• Product Owner
• Product Owner – Non Functional Requirement’s
• Product Owner/Technical Lead
• Program Manager
• Project Lead
• Project Lead and Scrum Master
• Project Manager
• Project Quality Manager
• Projects Manager
• PSC
• PSE
• R&D Director
• Release Manager
• Research Scholar
• SAP Practice Manager
• Scrum Master
• Scrum Trainer and Agile Coach
• Senior Agile Project Manager
• Senior Business Analyst
• Senior Consultant
• Senior Director
• Senior Engg
• Senior Engineer
• Senior Engineer – QA
• Senior Engineering Manager
• senior executive – quality
• Senior Group Manager
• Senior IT Project Management
• Senior Manager
• Senior Manager – Consulting
• Senior Manager – QA
• Senior Manager, Agile Coach
• Senior Manager-Technical Group head
• Senior Project Manager
• Senior QA Manager
• Senior Quality Assuarance Enginner
• Senior Software Developer
• Senior Software Engineer
• Software Architect
• Software Artisan
• Software Developer
• Software Developer (Embedded System)
• Software Engineer
• Software Manager – Technical Writing
• Solutions Architect
• Specialist
• Sr. Architect
• Sr. ASSOCIATE
• Sr. Engineer
• Sr. Director
• Sr. Engineering Manager
• Sr. IT Architect
• Sr. Manager
• Sr. Manager – Projects
• Sr. Project Manager
• Sr. Quality Manager
• Sr. Software Development Contributor
• Sr. Software Engineer1
• Sr. Vice President
• Strategy and New Product Development
• Student
• Supervisor Software Development
• Team Lead
• Tech Lead
• Tech. Specialist
• Technical Architect
• Technical Lead
• Technical Leader / Scrum Master
• Technical Product Manager
• Technical Project Lead
• Technologist
• Test Engineer Manager
• Test Engineer-2
• untitled
• Vice President
• Vice President – Global Agile Strategies
• Vice President, Process Design Consultant
• VP
• VP Solutions

From these 17 different countries:

• Australia
• China
• Denmark
• Finland
• France
• Germany
• India
• Indonesia
• Iran
• Japan
• Malaysia
• South Africa
• Sri Lanka
• Sweden
• Ukraine
• United Kingdom
• United States

At least 3-4 people I respect in the Indian software community have asked me:

Why are there so few Indian speakers at the upcoming Agile India 2013 Conference?

My question to them:

Should we pick speakers based on their nationality?

I strongly disagree. We pick speakers purely based on the quality.

I care a damn which country they belong to, what is the color of their skin, who they worship, which sports they like, which beer they drink, etc. These things should not and won’t matter.

Would I like more speakers from India, bloody yes. Which is why, we run tons of other smaller, local conferences in India. First we want them to speak at these local events, get good at it and then present at an international conference.

Also to give some more context around what went into making of the program this year:

Poor quality speakers at Agile India 2012 Conference was the biggest complain we got last year. Personally, I believe we had an issue with the speaker quality. Open submissions and open review, somehow just does not work that well.

To fix that issue, this year we identified some exceptional speakers with a proven track record. We asked them for proposals, picked the best proposals from them and created a program with many open slots in it. Then we opened the submission system like last year and invited speakers to submit proposals that best fitted those slots. Best proposals were picked and the program was created. This process went on for 3+ months.

Our single, most important driving goal during this process was to create a conference program that the best of the conferences will struggle to match. I hope you will support us in this mission.

In BetterConf, we have a feature which allows participants (or anyone for that matter) to select which sessions they plan to attend, create a custom URL and share it with their network.

Step 1: You visit the conference schedule.

Step 2: Click on the “Attend” icon to select a specific session.

If you want to de-select the session now, click on the “Skip” button. Also you’ll notice that on the top right hand corner, “My Schedule” shows (1) indicating that you have added 1 session to your schedule.

Step 3: Like this you can go through the program and select all the sessions you are interested in attending. Alternatively, based on your role, we’ve created a list of recommended sessions.

Once you select any role, the respective session will be highlighted, while the rest of them will be grayed out.

Now, you could skip some sessions and add some other sessions.

Step 4: Once you’ve selected all your sessions, you can select “Share” from the “My Schedule” drop down.

Selecting “Share” will bring up:

Note that we’ve generated an unique, short-url for you.

Step 5: Share this link on Twitter, Facebook or GooglePlus

or

Please make sure you keep the #AgileIndia2013 hashtag.

Jeff Patton, a.k.a Father of Agile-UX, is doing the most innovative work around product discovery, release planning, agile interaction design, and putting requirements into context. Jeff won the Gordon Pask Award in the year 2007, for his work helping establish what User-Centered Design means in Agile.

Jeff brings two decades of experience from a wide variety of products from on-line aircraft parts ordering to electronic medical records to help organizations improve the way they work. Where many development processes focus on delivery speed and efficiency, Jeff balances those concerns with the need for building products that deliver exceptional value and marketplace success.

We are thrilled to offer Jeff’s exceptional Passionate ProductOwner (CSPO) workshop at the Agile India 2013 Conference.

Recently, we caught up with Jeff and asked him the following questions:

Why the passion in product ownership?

First off, “Passionate Product Ownership” is a stupid title, because you can’t teach someone passion! However, I’ve always been involved in Product Development and Product Management, and I take the greatest pride from knowing that I’ve made a product or put something out into the world that other people use. The class focuses on understanding the business problems we are solving – the people who will use the product and understanding what their problems are. While I can’t teach passion, we can certainly focus on helping everyone understand that they are building products that help people, and that’s where the passion comes from.

The product ownership role is often defined as one of the most challenging roles defined in scrum, why is this?

Scrum and Agile processes in general, offer a lot of tactical guidance for how to get software built. But most Agile processes depends on getting the right person in the Product Ownership role – someone who already knows what to build.

This role difficult because you are responsible for building the right thing, and you are also responsible for communicating what that right thing is to a large group of people, sometimes in excruciating detail! In this class, one of the first things you’ll learn is that while there may be a single Product Owner who acts as a leader, product ownership is handled by a team of people. I’d rather that the role of Product Owner was named “Product Leader” and that whole teams take ownership. If you survive the class and adopt this way of thinking, you’ll be practicing a type of product ownership where everyone is involved in figuring out the details of what to do, who the user is, how best to help them and what solutions should be built and described in detail.

You’ve done significant work in blending UX & Agile. Where do you think the community is headed as far as UX on Agile projects go?

That’s a great question! It depends on which community you’re talking about. In the early 2000s, I spent a lot of time in the Agile community trying to help them understand what user experience was and its importance. Simultaneously, I spent time with User Experience people trying to help them not be so darn afraid of Agile Development as if it was going to “wreck” things.

I’ve seen a lot of maturation over the last decade and many UX people now have experience working inside Agile projects and teams. The coolest thing that’s happened within the User Experience community is that they have learned to change their practice so it works better in an Agile context. I’ve also seen more and more organizations working with Agile development recognizing the importance of understanding users and building products that people like. Organizations see that UX is the kind of work that happens outside the code and it isn’t an “engineering thing.” Currently, I am seeing the User Experience community going deeper and evolving practices that work better. For example, you’ll find books on Agile User Experience and Lean User Experience. Also more and more people who teach Agile practices acknowledge, or at least understand, what a user experience person does, although some challenges remain.

A new kind of Agile is forming, where the work that UX people do to understand users, prototype and try out ideas, is now called Lean Start-Up. A friend of mine, Leah Buley, once said, “Design isn’t a product that designers produce. Design is a process that designers facilitate.” The communities are starting to understand that the user experience work is cross-cutting and the concern is threading it’s way into everyone’s process.

What will be the key take away for the workshop attendees?

You will learn the practices that support the “Product Discovery” process and how to do discovery well. Building the right product is about understanding who the product is for and how they are going to benefit from using it. This is not a singular person’s responsibility – it is the whole team’s responsibility. The practices you’ll get in the class that support this come from user experience. Practices such as simple personas and story mapping provide understanding of users and model user behaviors. You’ll also get practices for good project management. For example, focusing product releases on specific target users, tactically guiding releases, ways to slice stories thinly to slowly build up a product, so that as soon as possible, it is a shippable, complete product. You’ll also gain practices for building small amounts of product as experiments to really validate if you are building the right product.

Limited seats are available for Jeff’s Product Ownership workshop. Book your seat today to avoid disappointment: http://booking.agilefaqs.com

Lasse Koskela will be presenting a workshop on ‘Test Driven Development Applied’ at Agile India 2013. He works as a coach, trainer, consultant and programmer, spending his days helping clients and colleagues at Reaktor create successful software products.

Lasse is also the author of books ‘Practical TDD and Acceptance TDD for Java Developers’ and ‘Effective Unit Testing’.

He is one of the pioneers of the Finnish agile community and speaks frequently at international conferences. He recently spoke at Agile2012.

We interviewed Lasse recently and asked him several questions related to one of his favourite topics TDD (Test Driven Development).

What are the mindset changes required by the developer(s) and team members when adopting TDD?

That would likely depend on the developer but I’d say that most often the biggest change required in one’s mindset is to acknowledge that you don’t know everything.

The more experience a programmer has the more likely they are to think of themselves as being “good”. A little confidence can be a huge boon to productivity but too much confidence creates blind spots–we literally learn to not question our assumptions and end up repeating the same old solution even if it’s not a very good fit.

TDD, on the other hand, makes us state some of those assumptions–such as what would be a good design for this class–in such concrete terms that it’s difficult to ignore the awkwardness when the same old solution doesn’t quite fit. It doesn’t fit and you can feel it through the difficulty you’re having writing a test for that design. Sometimes, you look at your test and go, “that doesn’t make any sense–much easier would be to…” And you end up changing the design.

How does TDD help developers in improving the art of software craftsmanship?

The process of programming test-first where you begin by expressing your intent from an automated unit test’s perspective has an almost magical effect on the kind of code you write. It’s much harder to write the kind of monolithic code we’ve all come to hate so much because the process of test-code-refactor invites you to create small, composable classes with clear responsibilities.

What I’ve also found is that TDD tends to help programmers learn what object-oriented design really means. It’s not just about encapsulating your code into “classes” but it’s about putting cohesive behavior into those classes. I wouldn’t go as far as saying that TDD makes you write object-oriented code but it certainly helps. I would say, however, that the better you understand object-oriented design the more comfortable you’ll likely feel test-driving code.

TDD is often perceived as slow, how does one justify the costs and benefits of TDD?

I haven’t heard that particular comment in a while but there certainly are a lot of skeptics when it comes to TDD. I guess every significant programming technique will have some skeptics. Skepticism is not a bad thing per se. In reasonable amounts a little skepticism is a healthy thing to have. That’s why I don’t try to persuade people to believe that TDD is good for them. I might believe but that doesn’t matter much. What matters is whether they themselves have an aspiration for becoming better. If you have that aspiration, perhaps you’ll give TDD a try and see for yourself.

With that said, there has been quite a lot of research into TDD–much more than around most other agile engineering practices–and that research seems to support the notion that TDD is a viable method for developing software. Research done at IBM and Microsoft, for instance, has measured that TDD (compared to a test-last approach) reduced defect densities by 40-90% while the management estimated that it added 15-35% to the time to implement a feature. The management had also concluded that the cost was far outweighed by the time and cost savings created by the reduction of defects.

I will repeat, however, that I don’t want you to take my word for it–or the researchers’ for that matter (especially without reading the research papers yourself). Instead, I’d like people to accept the possibility that they may or may not experience those reported advantages. If they decide to give it a try, even better. If they don’t, I hope they’re giving some other new technique a try. The absolute worst outcome would be that we stagnate at the status quo and stop improving on our profession.

What will be the key take away for the workshop attendees?

For first-timers the key take away is absolutely the first-hand experience of test-driving code. For people who’ve already dipped their feet into the water, I would expect them to walk out with the realization that their style of programming test-first is just one of many–some of which they’ve seen applied in the workshop–and with a resolution to try something slightly different when they get back to work. That’s something I am hoping to take away myself, too!

Seats for Lasse’s workshop are limited so book soon to avoid disappointment: http://booking.agilefaqs.com