Loading...
Latest news
How to Keep Your Product Strategy From Turning Into a Game of Jeopardy
The Maturity of your Market Dictates the Type of Product that You Need
Politics and your next release
What is a Successful Product? An Overview of Metrics and KPIs to Track Product Success
Product Management – You’re doing it wrong
Agile DevelopmentRoadmapsUncategorized

The Challenge – Planning a Full Year Roadmap When Working with Agile

raspler -

By Rivi Aspler

Moving from Waterfall to Agile mode of work encompassed many advantages. I will not dwell into these advantages as there are so many posts, articles and books that advocate Agile and I can easily be added to this admiring crowd.

But, as good as Agile is for managing the day-to-day definition and development processes of a cloud based product, it has certainly failed in finding a method that will enable product managers to plan and publish a long-term roadmap plan. The challenge is especially notable when one speaks of a product that should be installed on premise, at an SMB or an enterprise sized organization.

It is most common to see in RFPs questions about the full year roadmap.

The request is understandable. Don’t forget that the customer’s CIO has to justify the new expense, not only for the upcoming sprint but for the next few years (at least 2). We, as product managers on the vendor’s side, have to assist that CIO to bridge this gap, between the customers need to financially, operationally and functionally justify a long-term investment, and the scrum team willingness to commit only to the next sprint period.

And yet, as mentioned above, there is no good solution. Trying to tie long-term plans to Agile seems almost like an oxymoron. And yet, since we have to somehow discuss long-term plans, I have found the following as useful guidelines: (1) Define the big stones, (2) Define priorities rather than a timeline and (3) Communicate, communicate and once again, communicate.

——————————

(1) Defining the big stones

This is an easy one. I think that everyone anyway defines the big stones. When working with Agile, it’s even more important, since these are the only definite and clear items that one will be able to communicate, a year ahead, internally and externally. Budget wise, these big stones should get more R&D resources along the year.

(2) Defining priorities rather than a timeline

Here lies the challenge. Customers expect a clear timeline for a period of a year since SMB and enterprise sized organizations usually plan their budget a year ahead. Moreover, In many cases your deliverables as a vendor affect the customers’ internal IT timelines, resources allocation, budgets allocation etc. and therefore, if a vendor is unable to commit to a specific timeline, the customers’ on their side can’t plan their internal IT projects properly.

In such cases the following may occur:

  1. The customer may postpone the decision on the project till when the customer is certain that the new module/product exists.
  2. If this is a prospect, it is more likely to choose another vendor over you that will commit to a timeline. You may want to note that competitors will use this opportunity to trash you as a vendor that can’t commit to a timeline. A classic lose-lose situation.
  3. Assuming that the customer has decided to trust your intended roadmap (instead of a detailed timeline), you as a vendor will find yourself investing a lot of time negotiating and communicating priorities.

(3) Communication, communication and once again, communication

Working with agile and unable to commit to a full year roadmap plan, you will find yourself investing a considerable amount of time in communicating the Product, Release and Sprint backlogs. I have found the following actions as useful ones:

  • Present customers with the product backlog (using mockups and detailed excels)
  • Make sure the customer understands that deliverables will be added sprint-after-sprint.
  • Spend some time with the customer, explaining Agile mode of work.
  • Since you have no definite timeline to show, trust is an issue. Tackle that consciously. Invite the customer to an ‘Agile Day’ at your lab. This may assist you and the customer to understand each-other better.
  • Understanding SMB and enterprise sized organization processes, recommend a periodic upgrade, that is unrelated to the internal sprint periods. My experience is that an upgrade each 6 months gives customers enough ‘meat to chew on’ and doesn’t exaust them through their internal IT project management processes.
  • Keep on communicating your release and sprint backlogs, making sure that customers are into the details of the next release’s content.

Rivi

Tweet this: Planning a Full Year Roadmap When Working with Agile http://wp.me/pXBON-3n1 #prodmgmt #agile