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.

At the Agile Bengaluru 2010 conference, Sai Venkatakrishnan and Harikrishnan express their concern on the monotony that has crept into the way we develop application and how it affects us being Agile.

We follow agile, but are the systems we are building Agile?

A case study presented by Siddharta Govindaraj at the Agile Bengaluru 2010 Conference describing a period of 6 years in two startup companies that he was involved with.

The first part covers the period from 2004 to 2006 when Sidd was working with a startup based out of Singapore. He explains how we moved from doing ad-hoc development to adopting Scrum. Adopting Scrum was a big improvement over our previous ad-hoc approach but Scrum also led them to make some classic mistakes (from a lean point of view).

The second part covers the period from 2007 to 2009 when Sidd started his own company in India. The company was started with Scrum right from the beginning. He explains how we evolved from vanilla Scrum to Lean and Kanban.

This morning I got hooked to a new band. I’ve heard the band before and I’ve had others praise the band. It was only this morning, when I stumbled upon a particular song by the band and started enjoying it. After that I went and explore the whole album and other albums. Its been 8 hours and I’ve been tripping on their music.

To think about it, software is kind of same. Usually its one sticky (killer) feature that gets people hooked to a new software. Once they experience that feature, without much push, they discover all kinds of interesting features and innovative ways to use them.

As someone building a new product how do you figure out what that feature would be?

I’m aware of 2 approaches that have worked in the past:

• Agile/Lean-start-up philosophy: Build sketches (quick and dirty versions) of a few features, put it in the hands of real users and see what might click.
• Open Source/Eat your own dog food philosophy: Build something that addresses your personal itch and see if others have the same itch.

What other approaches have you seen work?