Have you encountered this situation?
You have multiple product teams working on different parts of the same product, each with their own Product Backlog and their own Product Owner. Each has gained deep knowledge of that area — they know what their user needs for that part of the product, and they take great pride in owning the tech stack for that part of the product.
However, there’s a problem — when you look at the list of Epics or Features, the different teams are working on them not in value order, but in the order of the local knowledge…
Once upon a time, I had the privilege of leading a Design & Copy team, back when I was working in the land of eCommerce. This was going back to pre-Agile days, and before Design Thinking was popularised. The concept of User Experience Design had not really existed, besides some hipsters at Google. Product Management was a typo for Project Management. Eric Ries had not yet put pen to paper on The Lean Startup. An Agile Coach was just a bus which was adept at doing three point turns. And yes, we did have colour televisions back then!
“We are terrified of uncertainty — we would rather be wrong than uncertain. We resist uncertainty of scope, technology, effort, structure. Embrace uncertainty; expect the unexpectable and anticipate ignorance.” — Dan North
It is human nature to crave certainty. What time will my bus arrive? When will my flight depart? Will the band show up on time for the wedding?
According the the Cynefin framework, these are usually obvious or complicated problems in terms of their complexity — good or best practices exist for reducing the risk in each. For the band to show up on time, they set off…
So you’ve created an inspiring Product Vision. You’ve moved towards a more outcome-based Product Roadmap, focused on problems to solve for your users. You’ve even started trying out OKRs, and using hypotheses to frame your more complex problems. This is awesome progress.
At the team level, Scrum/XP/Kanban are helping your teams deliver effectively. Your UX Designers and Product Manager are talking to users on a regular basis. However, when you talk to your teams, they still feel like they’re just churning out features— there to just execute.
When you talk to your designers, they’re saying their beautiful designs don’t look…
Last year, I had the privilege of taking the Coaching Agile Teams 3.0 (ICP-ACC) class in Stockholm with Lyssa Adkins and Michael Hamman. I highly recommend it. In this post, I’m going to share with you a new model I learned about and an example of how to apply it — my (now not so) secret weapon, the Integral Model for Agile Coaching.
I’ll be honest, I’m a big fan of models, and try to use them as a sense making tool a lot. However… remember:
All models are wrong but some are useful — George Box, statistician
I believe there is a missing link in Agile Product Development — one which causes lots of symptoms to look like problems further down the line, and something which is frequently skipped or glossed over in a one-page Powerpoint slide: the Product Roadmap.
A common misconception I hear a lot is that in an Agile environment, there is no need for roadmaps and no need for planning. This couldn’t be further from the truth — its just that these things work differently.
A Product Roadmap is a key communication tool for Product Owners and Product Managers, as to how we…