I’ve been a Wells Fargo customer since 2003, more than three years since the writing of this post, and generally, I’m satisfied with their online banking services. But, there are a few things that they get really wrong that just irk me. But instead of being just angry about it, I’m going to use it to discuss road maps and agile development, because, as I said when I began this post, I generally like their service. In what follows, I’m going to make a potentially large assumption that the Wells Fargo team is practicing some form of agile development.
One of the hallmarks of Agile Development is the phrase “YAGNI” — You Ain’t Gonna Need It. This phrase, when properly applied, empowers teams to deliver working software to their customers in a timely manner. Bravo!
Let’s consider, then, a particular interaction that I just hate about Wells Fargo online banking: You can’t edit the address of a payee. You can add one, you can delete one, but you can’t edit the address.
My best construction of how this made sense is that I can imagine a tense room filled with their online banking team debating the pros/cons of adding an “edit address” function to their web site. I can’t imagine why this would be hard, because the only reason it could be considered complex would be the need to retain historical information, but retaining historical information isn’t all that hard. But, let’s give the Wells Fargo developers the benefit of the doubt and assume it is hard.
I therefore imagine the meeting going something like this:
Product mgt: We need the ability to add, edit, and delete a payee.
Dev team: We can give you add and delete in the timeframe allotted, but that edit — whew. That’s tough. Don’t think we can do it.
Product mgt: That really hurts usability. Are you sure?
Dev team: Yeah, because of some reason I can’t imagine. Tell you what - you can simulate editing the address by deleting an payee and then re-adding it.
Product mgt: With no negative consequences, right?
Dev team: We don’t think so.
Sounds good, right? As an agilist, I fully support that they implemented what they thought was “good enough” to ship, and yes, if you really need to edit the address of a payee, you can delete and then re-add it. So, perhaps YAGNI of the “edit” was appropriate.
But the actual details of the implemention leave much to be desired. In fact, it really isn’t good enough, and they do need an “edit”. For those of who you don’t how edit relates to CRUD, it is the U - update (Create, Read, Update, & Delete).
As it turns out deleting a payee deletes the historical information about the payee (i.e., your record of payments). This is pretty nasty. And addresses change. So Wells Fargo really should implement an edit (update) function.
Which leads me to the importance of product roadmaps. In this case, I feel that someone lost the feature called “edit payee address” or allowed other features to take over. Instead, they should have implemented the add/delete operations and then, sometime later, implemented the edit functions. And this should have been part of the negotiation of the road map:
Product mgt: OK, I’ll accept that we can’t get edit in this release. But we need to be prepared to add it in the next release, and we may need to adjust our release plan if customers scream about it.
Of course, maybe after three years of using their service I’m over reacting. I mean, I’ve only requested it several times. Or, perhaps I’m the only customer who needs to edit the addresses of payees, or perhaps I’m the only one frustrated by the fact that you lose your history of payments when you delete a payee.
This doesn’t mean that Wells Fargo isn’t improving the functionality of the web site — several changes have been made over the past few years that have genuinely improved usability. I am not satisfied, however, with how their roadmap is guiding the development of their features, as there appears to be a fairly wide variation in what gets implemented. For example, you can create, read, delete a payee (but not update their address), create a monthly wire transfer (but not read, update, or delete it), and so forth. A good rule of thumb is to CRUD every object/entity in your system, and a road map that helps you do this is a useful tool.
Which leads me to another vitally important aspect of good road maps. I’d would really like it if Wells Fargo acknowledged my request with a brief statement about when it would be implemented — even if it is “never”. Instead, I simply get a response that says “Thank you for submitting your feature request”.
What would be better, of course, is if this feature is on the road map, that they tell me (roughly) when they expect it. It would be stellar if Wells Fargo would publish this road map on the web so that I could see it evolve.
Summary? Go ahead an be agile — get working software out the door as quick as you can. Then, listen to the feedback from your customers, and respond in a way that is equally as agile.
