.... or so some people may have thought.
A couple weeks ago I worked with Luke Hohmann from Enthiosys to facilitate the Agile Requirements Workshop here at the Borland Software headquarters in Austin, TX. We invited a local group of about 25 agilists in Austin from various companies. Some were executive level and some were team level. Some had small teams at small companies, while some hailed from very large companies with distributed teams. Overall, it was a very good cross-section of participants. Our team of about 8 people from Borland and Enthiosys worked as facilitators and observers. Our topic was aptly, "Agile Requirements".
What we hoped to understand more fully is the requirements process for Agile teams. Specifically, how requirements are identified, expressed, prioritized, validated, and organized in Agile teams? Our task was not to review the project management process... as sometimes we fell into. Rather, it was requirements we were interested in. Whatever you call them in your own shop: requirements; stories; use cases; user stories; or goals; we wanted to create a shared learning environment to discuss our experiences and then publish the findings for others.
One of the questions I personally had going into this gig was whether or not a high-performing agile development team would even need a traditional "roadmap". I wondered if these teams or companies execute so well that it lessens the need for a longer term vision into their future. Do they communicate so well across teams that the coordination of releases is not a problem? In short, do they need these stinkin' roadmaps?"
I asked myself this because traditional waterfall roadmaps can be a highly political artifact in some organizations, with many choosing to ignore the roadmaps altogether since they are so high level (stratospheric?) in nature. Is the same true for Agile? Have roadmaps been tossed into the dump heap of useless documentation along with the Functional Requirements Specification (FRS) as items that simply do not help teams perform better?
Which brings me back to our workshop observations. We found that the team and the leaders really wanted, and needed, to see farther down the road. In fact, not only is a roadmap important in Agile... it is probably more important than it ever was in waterfall.
The observations we made at our Agile Requirements Workshop were centered around the need to better find and prioritize the right market problems for the best profit. This is a roadmap issue. We heard comments like "I want to see further than just over the hood" which led us to the realization that roadmaps are needed in all organizations, and particularly Agile ones. Luke Hohmann wrote a good initial post about our observations, and there will be more coming as we put flesh on the experience report.
More about our experience at Borland
What we've done at Borland, with help from Enthiosys, is to implement and customize an Agile Roadmapping framework that helps us build more effective roadmaps using collaborative techniques with cross-functional teams. I presented a webinar with Pragmatic Marketing on this topic in November, along with Scott Gilbert from Enthiosys, that describes it pretty well. I'll expand on this topic later, but I will say that the implementation of this technique went extremely well and the results were outstanding. The legally blessed and approved "roadmap" document is then abstracted out of this exercise for sharing beyond the internal teams. We do this every quarter with every suite.
David at 37signals wrote that he believed roadmaps are not needed. David brings up great points about the misuse of roadmaps and how it may lead to dysfunctional behavior. But there is a big difference between an artifact called "the roadmap," and an activity called "roadmapping." Both will result in a roadmap. But doing the former without the latter (especially in an Agile environment) will lead to poor results, apathy or mutiny in the team, and a lot of silo'ed organizations.
What we REALLY need are roadmaps in Agile development teams! They should be built using Agile techniques... collaboratively, but focused on the business needs. Roadmaps should be refined regularly as a part of the product process so that you end up with a more effective, relevant, and cohesive product strategy in your organization.
Stay tuned for a future post that details Borland's experiences (good, bad, and ugly) as we transitioned to a more Agile approach to roadmapping and roadmap creation. In the meantime, I'd be curious to get your feedback. How do you build your roadmap and share it with your team(s)? What have you learned?