Episode Description

In one of my past memos to my list subscribers, I addressed some questions about agile and data products. Today, I expound on each of these and share some observations from my consulting work. In some enterprise orgs, mostly outside of the software industry, agile is still new and perceived as a panacea. In reality, it can just become a factory for shipping features and outputs faster–with positive outcomes and business value being mostly absent. To increase the adoption of enterprise data products that have humans in the loop, it’s great to have agility in mind, but poor technology shipped faster isn’t going to serve your customers any better than what you’re doing now.

Here are the 10 reflections I’ll dive into on this episode:

You can't project manage your way out of a [data] product problem.
The more you try to deploy agile at scale, take the trainings, and hire special "agilists", the more you're going to tend to measure success by how well you followed the Agile process.
Agile is great for software engineering, but nobody really wants "software engineering" given to them. They do care about the perceived reality of your data product.
Run from anyone that tells you that you shouldn't ever do any design, user research, or UX work "up front" because "that is waterfall."
Everybody else is also doing modified scrum (or modified _______).
Marty Cagan talks about this a lot, but in short: while the PM (product managers) may own the backlog and priorities, what’s more important is that these PMs “own the problem” space as opposed to owning features or being solution-centered.
Before Agile can thrive, you will need strong senior leadership buy-in if you're going to do outcome-driven data product work.
There's a huge promise in the word "agile." You've been warned.
If you don't have a plan for how you'll do discovery work, defining clear problem sets and success metrics, and understanding customers feelings, pains, needs, and wants, and the like, Agile won't deliver much improvement for data products (probably).
Getting comfortable with shipping half-right, half-quality, half-done is hard.

Quotes from Today’s Episode

“You can get lost in following the process and thinking that as long as we do that, we’re going to end up with a great data product at the end.” - Brian (3:16)
“The other way to define clear success criteria for data products and hold yourself accountable to those on the user and business side is to really understand what does a positive outcome look like? How would we measure it?” - Brian (5:26)
“The most important thing is to know that the user experience is the perceived reality of the technology that you built. Their experience is the only reality that matters.” - Brian (9:22)
“Do the right amount of planning work upfront, have a strategy in place, make sure the team understands it collectively, and then you can do the engineering using agile.” - Brian (18:15)
“If you don’t have a plan for how you’ll do discovery work, defining clear problem sets and success metrics, and understanding customers’ feelings, pains, needs, wants, and all of that, then agile will not deliver increased adoption of your data products. - Brian (36:07)

Links:

designingforanalytics.com: https://designingforanalytics.com
designingforanalytics.com/list: https://designingforanalytics.com/list

093 - Why Agile Alone Won’t Increase Adoption of Your Enterprise Data Products

Experiencing Data w/ Brian T. O’Neill