During last August's Agile 2010 conference, I attended a session that used a board game to simulate the collaboration between developers and UX professionals. The object of the game was to coordinate the schedules of these two groups, who normally follow the beats of different metronomes. On top of that basic timing challenge, unexpected events complicated this dance between development and UX.
While this session does show a novel application of serious gaming (one of my favorite topics, in case you hadn't noticed), the interesting aspect of this session is that it happened at all. Until recently, UX was not a major concern for Agilists – or most people developing software, for that matter. The phrase, "And then we'll throw a UI on top of it," summarized the indifference of all too many development teams to UX concerns.
In the last few years, many teams have learned a new attitude. Instead of treating UX as a tarpaulin, thrown over the application to clumsily hold it all together, UX is as much a part of the system as the technical architecture or the application logic.
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.
All next week, colleague Dave West and I will be at Agile 2010. On Monday, I'm doing a workshop on the effect of Agile in technology companies, in the rest of the organization beyond the development team. IT professionals might see a lot of similar effects in their organizations, too. The workshop is chock full of exercises, including at least one serious game. So, expect some Agile fun in the Orlando sun.
At the end of the week, Dave is doing a presentation on the new trend toward product-centricity in IT organizations. How do you combine two disciplines, Agile and productization, to achieve even better outcomes? Dave's a great speaker, so if you're going to be at Agile 2010, you'll kick yourself if you miss his session.
As Forrester analysts, we're always available to our clients for inquiries. If you're in Orlando with us, we'd be glad to try to set up an inquiry face-to-face instead of the typical phone call. Drop me a line at firstname.lastname@example.org if you're interested in meeting while we're at Agile 2010. See you there.
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.)
As I explained earlier this week, this is our first venture into Agile Research Development, a very different way of doing research. Since it's officially Agile, I'll use even the thinnest of excuses to explain how we're applying Agile principles. Pictured here is our Scrum Master, Eric Hsieh, taking a picture of our initial list of items that we're putting into the backlog. That chart sits right next to my desk in the Foster City office of Forrester, so I threw in another shot that gives a peek at the scenic view from my desk. (If you've never been to Foster City, it's the mini-Venice of the Bay Area. I could kayak to work.) Also taken from the Agile canon are the user stories that define how we expect the collaboration between us and the Forrester community to operate.
Today's a very exciting day for me. As you know, I'm a member of a team of Forrester analysts who write research specifically for product marketers and product managers in the tech industry. A few weeks ago, we launched a community for product marketers and product managers. Now, we're bringing those two activities together by including our PM community in every stage of a research project. Plus, we're using an Agile approach. And you're all invited.
(Role-based research. The voice of the customer, expressed loudly and regularly through social media. Agile as the vehicle for applying what customers say to the product we're developing, in the most rapid and substantive way possible. I guess we do read our own research.)
What's The Topic?
We've yet to meet a product marketer or product manager who isn't interested in thought leadership, given its attractiveness and elusiveness. Gaining recognition as a thought leader is only the first step. Having achieved that exalted status, how do vendors convert thought leadership into tangible business benefits?
For our first venture into this new research approach, thought leadership was an easy choice of topic: important, popular, practical, and manageable.
Where Does The Community Fit In?
The community has a bigger role to play in this project than just suggesting a topic. We need your suggestions and feedback throughout the entire research process, from inception to publication. For example, before doing the primary research, we'll draft a list of interview questions. Since thought leadership has no end of interesting aspects, we want to make sure that the questions we ask go straight to the issues that matter most to product marketers and product managers. Here are but a few examples:
In the technology industry, there has been a rising chorus of questions about the role of the executive in Agile adoption. The recent acceleration of Agile adoption has a lot to do with the frequency of the question. Here's the other reason: Agile has been around long enough for a collective contemplation of lessons learned. In the after action reports about Agile implementations, executives regularly appear as major characters.
Given the ripple effects of Agile adoption throughout a technology company, it would have been surprising indeed if executives had played only a minor role. When the development team changes when and how it delivers new technology, everyone (Sales, Marketing, Support, Consulting, etc.) is affected in some way. With Agile adoption, executives who are already trying to bring departments into greater alignment face another potential source of misalignment. At the same time, as Forrester's research into Agile adoption in the tech industry shows, executives are less able to influence the priorities and activities in Development. If the executives don't really understand Agile, or haven't invested much in making this profound transformation work, an avalanche of backlash from the upper regions of the org chart is the usual result.