Hard to create a great customer experience in an agile context


(Philip Durbin) #1

I’m reading Sense & Respond by Jeff Gothelf and Josh Seiden (subtitle: How Successful Organizations Listen to Customers and Create New Products Continuously) and on page 135 they say,

“It can be hard to create a great customer experience in an agile context.”

They talk a bit about experience debt, comparing it to technical debt, and go on to say,

“Designers want to be able to go back and improve things by iterating: working on the feature again. But project owners, whose performance is sometimes measured by how many features they release, may feel pressure to move forward to the next release.”

This really resonates with me. There’s always a new feature to work on, which is fun, but there’s often some polishing I’d like to do on older features, especially once feedback starts rolling in.

What have your experiences been?


#2

I’m on the same train, I would love to improve existing features, but it seems no one else cares about it enough to go “back” and polish.
I don’t think necessarily that it can be hard, it’s mostly having the right team. If the CEO or CTO cares enough about delivering a great experience, they will invest in it.


(Jdittrich) #3

I agree with polishing/reacting on feedback being difficult – I don’t know if agile makes this particularly difficult, though.

With agile development, some practices like iteration, technical debt, refactoring might enter a work environment which make improvement on existing features more likely (Assuming that the engineering framing is often the strongest, and that one could “attach” a less powerful concern to it: “Our engineers mention technical debt and we said we want to fight it. In design we have a close equivalent we should also tackle…”)

I am more of the impression, that activities that don’t generate any immediately graspable result can diminish under the agile mindset: User need research, exploration of unknown fields etc. (Though they have not been strong in many non-agile practices we had before)


#4

Agreed, I have found difficulties with activities that are more on the qualitative side of things, even things such as incremental improvements, even with upper-management buy-in. I could say this is because there’s already a roadmap for the next two years and this(polish/improve something) is deviating from that.

“Out of sight kanban, out of mind”