Did you know how truly diverse the Agile India 2012 conference program committee is?

That’s right! We have over 100 members from 21 countries.

To be successful in an agile environment, IMHO team members need to learn the following skills:

• Embracing uncertainty/change and finding effective ways to deal with it.
• Tight collaboration and communication with everyone involved.
• Collective Ownership, Drive and Discipline to getting things done.
• Eliminating Wasting: Mercilessly looking for waste and trying to eradicate it.
• Fail-fast: Breaking a large problem down into small safe-fail experiments and then willing to try & learn quickly.
• Systems thinking: Understanding how things influence one another within a whole system and avoiding local optimizations.
• Critical thinking: Reasonable reflective thinking focused on deciding what to believe or do. In other words; thinking about thinking.
• Open to experimenting with radical ideas

Gentle reminder, the early bird submission for the Agile India 2012 Conference closes on 26th Sep 2011.

Visit our submission system to get started.

Some resources to help you with your submission:

• How to Submit a Proposal?
• Everything You Should Know about Submitting a World-Class Proposal
• Early Bird Submission: What’s the big rush?
• Overview of the Review Process
• Important Milestones
• Compensation for speakers

Update: Stage Proposals are closed.

Sessions proposals are open now; visit: http://submit2012india.agilealliance.org/proposals

Agile gave us a wonderful head-start in a different direction than the one we’ve used to (heavy weight methods.) Personally I feel we’ve got as much value we could. Now its time to start thinking from a different direction, building on what we already know and to some extent unlearning some things we know.

Wait a second, isn’t Agile all about “Inspect and Adapt”?

There is a limit to “inspect and adapt”. If you look at the Lean movement, most people talk about Kaizen (small gradual change, change for the good, which is in-line with inspect-and-adapt). But very few people talk about Kaikaku (disruptive change or transformation).

Remember Agile was Kaikaku for most of us in late 90s. And then we’ve applied Kaizen to it for many years. IMHO now its time to apply Kaikaku again.

Have an idea? Want to challenge some Agile practices? Like to share your experience?

Lightning talks, is your opportunity to share your ideas or experiences in less than 10 minute.

Send your talk proposal to lightningchair@xp2011.org before Jan 7th 2011.

More about the conference: http://xp2011.org/

I hear many people claim Agile is just common sense. When I hear that, I feel, these guys are way smarter than me or they don’t really understand Agile or they are plain lying.

When I first read about test-first programming, I fell off the chair laughing, I thought it was some kind of a joke. “How the heck can I write automated tests, even without knowing what my code would look like”. You think TDD is common sense?

From traditional methods, when I first moved to monthly iterations/sprints, we were struggling to finish what we signed up for in a month. Its but natural to consider extending the time. Also you realize half day of planning is not sufficient, there are lot of changes that come mid-sprint. The logical way to address this problem is to extend the iteration/sprint duration, add more people and to spend more time planning to make sure you’ve considered all scenarios. But to nobody’s surprise but your’s spending more time does not help (in fact makes things worse). In the moments of desperation, you propose to reduce the sprint duration to half, may be even 1/4. Surprisingly this works way better. Logical right?

And what did you think of Pair Programming? Its obvious right, that 2 developers working together on the same machine will produce better quality software faster?

What about continuous integration? Integrating once a week/month is such a nightmare, that you want us to go through that many times a day? But of course its common sense that it would be better.

How about showing working software demos weekly/monthly somehow magically improving collaboration and trust. Intuitive? And also shipping small increments of software frequently to avoid rework and get fast feedback?

One after another we can list each practice (esp.the most powerful ones) and you’ll see why Agile is counter-intuitive (at least to me in early 2000 when I stumbled upon it).

A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.

How do you know you are ready to start iterating? In some cases, very little is needed before the first iteration. In other cases, rushing to iterate (because you were told to) can lead to weeks of time wasted overly focused on delivering a poorly understood product.

In this presentation by David Hussman titled Getting Ready to Produce at Agile Mumbai 2010 Conference, David provides concrete tools for discovering your product context and assessing whether you are ready to start building and / or iterating. Participants learned tools for defining how much process you need and tools for truly understanding what you are building and why, as well as who will use it, why they will (or will not) use it and why.

10 years after the introduction of agile methods, many communities are succeeding in their adoption while others are struggling or failing. Why? Many struggle because agile methods were introduced in an overly prescriptive manner. People were told to follow a set of practices instead of learning to use the agile practices and values to amplify their existing strengths and address their challenges.

In this talk, David Hussman shares successful coaching techniques he uses to grow sustainable agility that lasts beyond the early iterations or the first few agile projects. David begins with a series of tools to help you build a solid foundation: assessments, pragmatic practice selection, chartering and product planning tools. He then moves on to discuss ideas for finding a groove of discover and delivery that is best suited to your project community.

As a full time working coach, David uses coaching stories and experiences to discuss establishing strong cadence while also building the essence of coaching and coaches in your community Whether you are new to agile methods or you are a seasoned players, this session will help you grow your coaching skills and your ability to truly discover and deliver real value.