Internal pilots (a.k.a. "eating your own dog food," or "drinking your own champagne") are important tools. But how? What kind of feedback do you get from these exercises, and what sort don't you get?
That's the topic of a new research project that we just launched. While Forrester starts hundreds of new research efforts this year, I'm highlighting this one for two reasons: (1) I'm doing the research, and I think that everything I do is interesting; (2) this is the second time I've done a research project in a very transparent way. From start to finish, we're going to work in the open, to give you, Dear Reader, an opportunity to comment on the research as we do it.
The first project done in this fashion, which investigated "thought leadership" (whatever that means) in the technology industry, resulted in this RoleView document. Along the way, we solicited comments on the basic research plan, the questions we asked our interview subjects, and the content of the document. We threw out questions to Forrester community members along the way, and at the end, we did a brief retrospection on how well we succeeded.
We're Interested In Your Feedback Again. No, Really.
We're following the same game plan this time. Three documents just went live in The Forrester Community For Application Development & Delivery Professionals:
Our first application of Agile principles to the research process, which occurred during our study of thought leadership in the tech industry, was a very Agile-esque journey into the unknown. We learned a great deal that applies to future applications of Agile Research Development, so here's my retrospective.
You Can Be Agile Up To The Boundaries Of What You Control
Ultimately, you control only part of the value stream. This maxim holds true wherever you apply Agile, and software developers learn this principle right away. You can be the most disciplined developer imaginable, never checking in code that doesn't work, always building in tests, and still be at the mercy of your own QA team. And even if the larger team, including testers, works in blissful harmony, someone needs to deploy the code on a live system. (Which is why dev ops is receiving a lot of attention from within the Agile community these days. See Jez Humble's recent book for a good example.)
If a stream is an appropriate metaphor for value creation and delivery, then this stream always takes many twists and turns, frequently encountering dams and obstructions. The success of Agile, therefore, depends to a great extent on eliminating these kinks, navigating around them, or learning to accept them as part of the value stream's trajectory.
As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)
As I said in my last blog post, we're looking for feedback on the questions we're asking about thought leadership in the technology industry. At the same time, we realized that it has been a while since we held an open house in Forrester's Foster City office. (If you're not aware, we did a few informal sessions for product managers and product marketers, to give people in that role an opportunity to talk amongst themselves about topics of interest, sprinkled with whatever useful information an analyst like myself can provide.) Suddenly, a spark leaped across the two neurons carrying these separate ideas.
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.
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.
Today was our first official update to the research plan (a.k.a. the development document) for our project investigating thought leadership in the technology industry. A quick refresher: this particular piece of research is our first venture into Agile research development, which (1) applies Agile principles to our research, and (2) opens the project to the community to participate in the research process from start to finish. In other words, we're using the newly-launched Forrester Community as the forum where the voice of the customer will speak directly to us about our research as we're doing it.
You can see the current development document, including the updated text and the comments that inspired those changes, here. As promised, we're also maintaining a change log for tracking these changes over time. (The development document is also versioned, so we can look back on the history of edits through that mechanism, too.)