One of my teams recently went through a session to develop a product roadmap, using a technique based on the teachings of Luke Hohmann in his book Beyond Software Architecture. A roadmap is the oft-forgotten second level of agile planning—vision being the first, and release planning, iteration planning, and the daily plan being the other three (and comprising the bulk of agile texts). The roadmapping process got high marks from everyone involved, and at many times it was great fun!
We’d allocated two days for the exercise and invited an even wider group of aspects than usually participate in our scrums: development, QA, documentation, product management, sales, usability, marketing... you get the idea. Numbering almost half the crowd, the engineers were by far the largest contingent. Most of the broader dev team is new to agile and had never experienced a roadmap session, and frankly were rather skeptical. They saw this activity as largely a Product Management (PM) function and were expecting to be bored at best, with two days wasted at worse. Instead, they found themselves engaged and active participants, helping to plan not only the individual features but the aggregate product itself.
Like many agile practices, the benefits of roadmapping were not predictably obvious. What looked to dev like a gathering where they were going to sit at the back of the room and text their friends while the PMs and marketing folks argued turned out to be quite interactive; even those folks that didn't speak up during the two days commented afterward how illuminating it was to "see how the sausage was made". Before the session, the engineers were not looking forward to the meetings; afterward, they are asking when the next one will be!
Comments