Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Radical Roadmapping - Creating Synchronized Agile Product and Technology Roadmaps PCA17

815 views

Published on

This session will discuss why a company would create and maintain three major artifacts - Innovation Roadmap, Infrastructure/ Platform Roadmap, and Operations/DevOps Roadmap - as well as the process to do so. Further, it will cover how to synchronize them in order to move away from making "OR" decisions to making "AND" decisions that will please all stakeholders. It will also discuss key cultural changes that must be present in order to achieve maximum benefit from this approach and challenges experienced along the way to making this a reality at Socialware, a SaaS product company. Finally, this session will include real world examples of the evolution of these roadmaps over 18 months that participants can take away and use as guidelines for their own situations.

This was presented at the Keep Austin Agile 2016 conference, the #AgileAustin Product SIG and Product Camp Austin 2016 (#PCATX17)

Published in: Software

Radical Roadmapping - Creating Synchronized Agile Product and Technology Roadmaps PCA17

  1. 1. Radical Roadmapping: Creating Synchronized Agile Product and Technology Roadmaps Product Camp Austin 17 6 August 2016 Matt Roberts , VP Product Engineering @ContinuumAnalytics matt@matt-roberts.com | @MulticastMatt linkedin.com/in/cpgmattr multicastmatt.blogspot.com
  2. 2. Abstract: This session will discuss why a company would create and maintain three major artifacts - Innovation Roadmap, Infrastructure/ Platform Roadmap, and Operations/DevOps Roadmap - as well as the process to do so. Further, it will cover how to synchronize them in order to move away from making "OR" decisions to making "AND" decisions that will please all stakeholders. It will also discuss key cultural changes that must be present in order to achieve maximum benefit from this approach and challenges experienced along the way to making this a reality at Socialware, a SaaS product company. Finally, this session will include real world examples of the evolution of these roadmaps over 18 months that participants can take away and use as guidelines for their own situations. This concept is RADICAL as it is innovative in both its novel approach and ability to drive enormously positive organizational agility.
  3. 3. Bio: Matt Roberts is an Agile pragmatist continuing his lifelong learning journey, currently serving customers and innovators throughout the complete value chain as VP of Product Engineering for Continuum Analytics. His experience is wide-ranging as he has developed software and led efforts to create systems for product development teams to deliver innovative solutions in companies ranging from early-stage start-up to publicly-traded companies in both consulting and full-time roles. He has had the privilege of serving the Austin software development community as Agile Austin President for four consecutive years and as Secretary for the IEEE Computer Society for two years. Among others, Matt holds certifications as a Certified Scrum Practitioner (CSP), Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Innovation Games, and Pragmatic Marketing.
  4. 4. My Goal Deliver the highest quality value to the customer while maintaining worker safety. This is accomplished by harnessing ongoing change through continuous: Learning Planning Alignment Risk Reduction / Options
  5. 5. “Business people and developers must work together daily throughout the project.” “Continuous attention to technical excellence and good design enhances agility.” “Responding to change over following a plan” “Simplicity--the art of maximizing the amount of work not done--is essential.”
  6. 6. Naming Disambiguation Trying to make this applicable to various teams in product development (deployed and SaaS) and IT, and reduce the use of “strokes,” here’s what will be the standard for this presentation Product = “Business” “The Business” “Innovation” Platform = “Technology” “Infrastructure” “Debt” DevOps = “CI” “CD” “CM” “Security” “Ops” “IT”
  7. 7. “What Problem Are You Trying to Solve?
 Ability to communicate to stakeholders the near-term and long-term goals of the entire product organization as things CHANGE Continuous alignment of customers, business, and development / technology teams from a medium to longer-term planning perspective Building trust across Product, Platform, and DevOps and maybe, just maybe into customers Ability to make tradeoffs and understand the full impact across all fronts A great deal of work is not represented in traditional roadmaps How much do we invest in infrastructure and why should we?
  8. 8. Matt’s Assertion The process of creating and continuously updating product roadmaps can be applied to underlying and related technology and operational changes that require investment for fun and profit
  9. 9. Roadmaps - Biz Perspective This is the future and we’re excited! These are all our !TOP SEKRET! master plans - don’t show it to anyone! We don’t have time for infrastructure work - we’re already late We don’t want to be held hostage by our customers to old roadmaps Note - I watched ST TOS in the 80s - TNG metaphor didn’t apply
  10. 10. Roadmaps - Dev Perspective Who’s going to do all this work? Thanks for a free lunch, now please let me get back to what’s important No one talked to me… How are we going to get all of this done without infrastructure improvements? What about DevOps? When was the last time this thing was updated? Note - I watched ST TOS in the 80s - TNG metaphor didn’t apply
  11. 11. Whatcha Gonna Git Today? A general model of a product roadmap A model set of synchronized roadmaps that span Product, Platform, and DevOps, with an specific focus on Platform and DevOps An example of a process to ensure that the roadmaps are continuously updated and made visible across organizational boundaries “Fun” stories about what’s worked and didn’t work A few laughs (hopefully), some snarkiness A chance to provide feedback
  12. 12. What this presentation isn’t about Product management tools and tooling Product capability prioritization techniques Product marketing and positioning techniques Estimating (bonus at the end) Product strategy Kittens (but here’s a cat)
  13. 13. What is a Traditional Roadmap? Bucket of product features over time Hopes, dreams, wishes Infrequently updated Pretty Top SekreT
  14. 14. When is a roadmap generally used? Funding (Start-up, New Line of Business, etc.) Annual planning Quarterly meetings Critical customer presentations Product Portfolio Strategy Build vs. buy Acquisition
  15. 15. Roadmap Examples
  16. 16. Hardware Roadmap
  17. 17. Big Enterprise Software Example
  18. 18. Enterprise Software Product Roadmap
  19. 19. Enterprise SaaS Roadmap
  20. 20. “Like” - Variable Time Horizons Closer is Wider and Longer Term Narrower - Allows for more detail in the short-term - More strategic / high-level in the long-term
  21. 21. “Like” - Customer Personas Financial Services Firms’ Compliance Officers, Financial Advisors, Information Security Team, Corporate Marketers, Brand Marketing and Legal
  22. 22. “Like” Customer Personas Swim lanes are specifically targeted at customer user personas that are appropriate for the product or service
  23. 23. “Like” Fuzzy & Friendly Roadmap items are primary written in terms that the customer persona / users will understand easily Themes on the top, detail expanded with epics Just the right amount of detail allows flexibility / interpretation as we learn
  24. 24. “Like” Fuzzy & Friendly Boundaries of boxes are “fuzzy” allowing change Epics are prioritized so stakeholders can understand what comes first Continuous Themes are OK with prioritized epics
  25. 25. General Roadmap Benefits Long-Term Planning User Value-Based Visible Explicit Holistic / High-Level Trade-Offs Risk
  26. 26. What if we could apply the same roadmap techniques to Platform and DevOps? What if we could apply the same techniques to Platform and DevOps long-term planning?
  27. 27. Radical RoadmapS AND Product (Traditional) Platform DevOps Short-Term (Optional) Others (potentially)
  28. 28. Socialware Radical Roadmaps
  29. 29. Product
  30. 30. DevOps
  31. 31. Platform
  32. 32. Example - Q1 ‘15 Ranked Goals 1. Ship Social Content Recommendation 2. Support Facebook API changes 3. Fix broken search technology 4. Scalable archive 5. “The Rest”
  33. 33. Product Platform DevOps
  34. 34. Goal Alignment - Product
  35. 35. Goal Alignment - DevOps
  36. 36. Goal Alignment-Platform
  37. 37. Agile Planning Flame Radical Roadmapping
  38. 38. Implementation Product Roadmap usually exists - if not, start there Platform Roadmap is challenging, but it usually is easy to set once there is a good Product Roadmap - It should be very much in sync! DevOps Roadmap is the most challenging, although with SaaS it can be much easier with a Product and Platform Roadmap. Again - keep it in sync Short-term roadmap can help connect short- and long-term efforts The first set of roadmaps will have wide variances in accuracy. With more time, practice, visibility, and adaptation they will be extremely useful Continuously update
  39. 39. Synchronization Synchronization means that business drivers are connecting all of the technical decisions Business drivers include things like customer value, risk, ROI, company strategy, option theory/MVP These are absolutely the most important conversations to have as they allow value to pull all work through the system Eliminating waste is a key aspect of this effort
  40. 40. Inspect and Adapt Update continuously Scrum: At the end of every sprint Kanban: Periodically—once a month max Items multiple quarters out generally don’t change much as they are more strategic and high-level in nature (hint: write them that way) Keep pushing at making them more visible
  41. 41. Radical Roadmap Rules Users, users, users, users (personas better), especially for non- product items - who cares and why? Not all roadmap items will link together, but the organizations’ goals must Planning horizon is important Think product features AND platform AND DevOps Think capacity Continuously update, be explicit, and be real Share as much as possible
  42. 42. Other Roadmaps Short-Term Partner-Delivered Functionality Capacity Allocation Fun story there about 12-month team member allocation for customer insight (ducking for cover in a room full of agilists) ANYTHING to help get visibility into value, risk, and tradeoffs over the medium- to long-term
  43. 43. Haters Gonna H8 My tool doesn’t support this / don’t have time to work with the API That’s a TON of work to do manually Three roadmaps—that’s way too much Actually, I had 7 at one point We can’t share our confidential plans with the team Technical roadmaps are not valuable - we need to ship features and focus all our efforts there
  44. 44. NOT responding to change Planning in silos Updating less than once a quarter Ignoring cross-cutting concerns Highly secretive environment Violation of Agile Principles and Values Radical Roadmapping #Fail
  45. 45. Dev & Ops Perspective Radical Roadvmapping is considered RAD by Developers because: There is more visibility across the organization of the real current state. The underlying technology work is made visible, is prioritized, and stands with features Their work is a first-class citizen They can start to think long-term and extend their stewardship
  46. 46. Business Perspective Radical Roadvmapping is considered RAD by the Business because: Long-term planning is a relatively easy exercise and the team isn’t afraid of engaging in what-if scenarios. The full costs/risks can be discussed Developers start communicating in ways they understand
  47. 47. Breaking “Rad” Real visibility and quick tradeoffs possible across an entire product development and operational environment Continuous learning organization where the business, the developers, and customers can work honestly and together on long-term planning as things change Culture embraces Agile principles and values
  48. 48. Fact Check - Matt’s Assertion The process of creating and continuously updating product roadmaps can be applied to underlying and related technology and operational changes that require investment for fun and profit
  49. 49. Powerful Prioritization Techniques Kano Model - Categorization of product capabilities by customer satisfaction over time Buy-A-Feature - Innovation game that allows groups to form consensus over value Can be applied to Platform and DevOps efforts too! All of the Innovation Games! Product Canvas - Achieve Fast Alignment
  50. 50. Product Roadmap Tools Powerpoint and Excel/Sheets :) Stickies and a wall Aha! Portfolio for Jira Trello So many more…
  51. 51. - Dwight D. Eisenhower “Plans are useless, but planning is indispensable”
  52. 52. - Kert Peterson “Agile is the Art of the Possible” - Kert Peterson “Agile is the Art of the Possible”
  53. 53. Related Work Continuous Agile Planning That the Biz and Dev Folk can "Like Like” by Matt Roberts bit.ly/252w4nk
  54. 54. Matt Roberts VP Product Engineering @Continuum Analytics matt@matt-roberts.com | @MulticastMatt linkedin.com/in/cpgmattr multicastmatt.blogspot.com Feedback is appreciated! Rad! >> bit.ly/pcatx17

×