We're now in Phase II of our first venture into Agile Research Development, an investigation of thought leadership in the technology industry. Phase II is when we start the actual primary research, and again, we're looking to the community for their help and guidance. The story so far:

• Published the development document, which explains how we'll proceed. Supporting documents, such as this overview of Agile Research Development, are also part of the project dossier.
• Incorporated feedback from the community into the development document. Many thanks to everyone who provided suggestions and criticisms of the original research plan, as described in the development document. In fact, if you haven't read the comments on the development document, I strongly recommend that you do. There are some real nuggets in there about a thought leadership, a topic of vital importance to tech vendors, their partners, and their customers.
• Drafted the interview guide. We now have a list of questions that we'll ask the interviewees, including both vendors and customers.

How You Can Help
First, we need another round of review. This time, we're looking for your feedback on the interview guide. Are these the questions you want answered? Have we missed anything? I've annotated the interview guide to explain some of the reasoning behind the current draft, which is my way of getting the discussion going.

We're also looking for help in arranging interviews. We've made some contacts with the two vendors under consideration, salesforce.com and Wipro. We also want to talk to customers of these two firms. If you know a good interviewee in either company, or among customers, please contact me (tgrant@forrester.com) or Eric Hsieh (ehsieh@forrester.com).

What We've Learned
Applying Agile to the research process resembles Agile in software development in at least one aspect: learning and adapting. For example, today I had a conversation with one of the stakeholders in this project. It was déjà vu all over again, with me, the product owner, asking the stakeholder to clarify his requirements. Even some of the language was lifted from my time in the tech industry: "Are we talking about a requirement, or an implementation to meet a requirement?"

Pictured to the right is another one of our key stakeholders, Peter Burris (my boss and the research director for the Technology Product Management & Marketing role), and Eric Hsieh, our Scrum Master who's keeping us on track. We were wrapping up our review of the interview guide when I snapped the picture. 

I also learned that it's hard to juggle a five-day conference and an Agile-paced research project. Agile 2010 was, once again, a top-notch, high-energy week of fascinating conversations about Agile and related subjects. Plus, colleague Dave West and I had to take the opportunity to talk to as many vendors as possible about their product and service offerings for Agile teams. Getting my regular work done, including this research project, got squeezed out of the schedule. Consequently, we're pushing the schedule back a week for all the remaining landmarks in this project.

So, in an O. Henry-like twist, the Agile conference conflicted with Agile Research Development. Whaddaya know.