Upload
matt-roberts
View
373
Download
0
Embed Size (px)
Citation preview
Radical Roadmapping: Creating Synchronized Agile Product and Technology
Roadmaps
Product Camp Austin 17 6 August 2016
Matt Roberts , VP Product Engineering @ContinuumAnalytics
[email protected] | @MulticastMatt linkedin.com/in/cpgmattr
multicastmatt.blogspot.com
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.
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.
My GoalDeliver 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
“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.”
Naming DisambiguationTrying 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”
“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?
Matt’s AssertionThe 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
Roadmaps - Biz PerspectiveThis 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
Roadmaps - Dev PerspectiveWho’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
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
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)
What is a Traditional Roadmap?
Bucket of product features
over time
Hopes, dreams, wishes
Infrequently updated
Pretty
Top SekreT
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
Roadmap Examples
Hardware Roadmap
Big Enterprise Software Example
Enterprise Software Product Roadmap
Enterprise SaaS Roadmap
“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
“Like” - Customer PersonasFinancial Services Firms’
Compliance Officers, Financial Advisors, Information Security Team, Corporate Marketers, Brand Marketing and Legal
“Like” Customer Personas
Swim lanes are specifically targeted at customer user personas that are
appropriate for the product or service
“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
“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
General Roadmap Benefits Long-Term Planning
User Value-Based
Visible
Explicit
Holistic / High-Level
Trade-Offs
Risk
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?
Radical RoadmapS
ANDProduct (Traditional)
Platform
DevOps
Short-Term (Optional)
Others (potentially)
Socialware Radical Roadmaps
Product
DevOps
Platform
Example - Q1 ‘15 Ranked Goals1. Ship Social Content Recommendation
2. Support Facebook API changes
3. Fix broken search technology
4. Scalable archive
5. “The Rest”
Product
Platform
DevOps
Goal Alignment - Product
Goal Alignment - DevOps
Goal Alignment-Platform
Agile Planning Flame
Radical Roadmapping
ImplementationProduct 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
SynchronizationSynchronization 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
Inspect and AdaptUpdate 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
Radical Roadmap RulesUsers, 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
Other RoadmapsShort-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
Haters Gonna H8My 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
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
Dev & Ops PerspectiveRadical 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
Business PerspectiveRadical 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
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
Fact Check - Matt’s AssertionThe 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
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
Product Roadmap ToolsPowerpoint and Excel/Sheets :)
Stickies and a wall
Aha!
Portfolio for Jira
Trello
So many more…
- Dwight D. Eisenhower“Plans are useless, but planning is indispensable”
- Kert Peterson“Agile is the Art of the Possible”
- Kert Peterson“Agile is the Art of the Possible”
Related WorkContinuous Agile Planning That the Biz and Dev Folk can "Like Like” by Matt Roberts
bit.ly/252w4nk
Matt Roberts VP Product Engineering @Continuum Analytics
[email protected] | @MulticastMatt
linkedin.com/in/cpgmattr
multicastmatt.blogspot.com
Feedback is appreciated!
Rad! >> bit.ly/pcatx17