User Story Showdown

One day I was reviewing a list screen in the development den and hit a brick wall. The application queue page had been developed by the senior architect of the team, a bearded philosopher type who had deeply absorbed the agile mantra to ‘maximize the amount of work not done.’ For this fellow, the answer was automatically ‘no’ until you made your case. I’m sure you’ve met one or two of these in your travels.

The screen in question was a list of transactions and they had some common attributes. That is, multiple lines could have the same description or the same type. Anxious to make what I thought was an easy improvement, I suggested that we add a ‘Row’ or ‘Item’ number column – something that the user could click on to open that row. The architect insisted that any other column could be used for that. A new column was not needed. The identifier column was indeed added to the list, but not that day. That day I left the room with hurt feelings and an important lesson in hand.

I failed to make the case for the new column. The change seemed logical to me (and, in fact, was) but I approached the feature based on my own desire and experience rather than bringing the team a value-based User Story that carried the weight of a real stakeholder. It is a lesson I would repeat until I fully embraced the principle that development team members are not application stakeholders. Only the voice of a real customer carries authority in a feature User Story.

Silos Sink Scrum


As a systematic way of delivering results, Scrum is beautiful. I have created business software for over thirty years and seldom seen anything as beautiful as a well-oiled Scrum team. The rhythmic dance of defining, designing, and delivering high-value features is delightful to watch and rewarding to perform. But it can be done oh so poorly if you don’t believe in the principles on which it rests.

“As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”
~ Harrington Emerson

There is nothing inherently smart about computers. They can produce stupidity at lightning speed and if you feed them garbage, they will produce giant piles of the same.  Something similar can be said of Scrum teams. If you wrap them in confusion and feed them crap, they can produce expensive tomes of shelf-ware.

As a method, Scrum can help you build a sustainable team that delivers more features with less waste than other systems. But that alone won’t ensure success.

The lovely tool that is Scrum must be undergirded by some bedrock principles that are bigger and more important than any method you might choose. Try not to laugh at these. Project obituaries are littered with teams who got them wrong.

Engage your Customers

Do you know what the hardest question in the Retail trade is? It’s not how to design a great product or write compelling sales copy or minimize logistics. It is the seemingly innocent query, “Who is your customer?” It’s the customer collective – all the real consumers of your product – that will guide you toward success. Identify them early and get them involved in shaping the product.

One key mistake is using a liaison from only one functional area. They know their department well but cannot represent other product users accurately. Another is ignoring executives or assuming that they are too busy to participate. These stakeholders often need critical reports that you won’t know about until you get a black eye for missing them.

Surrogates (and let’s be honest, a Product Owner is often just that) can help but should not be allowed to insulate you from the actual everyday users of the product. If you don’t believe that your customer knows what they want and can communicate it openly to you, then you have no way to win the game you’re playing. Agile software failure sounds like this: “The users don’t know what they need. Let’s build what we think is right.” Don’t let cynicism or arrogance blind your team by removing customer input.

Ship Early and Often

You don’t really know if the product is right until the customer says so. Shipping is necessary to get that feedback, so ship often. A good solution in customer hands is better than a perfect one stuck in the lab. To get feedback even faster than you can release, provide a sandbox users can play in and reward them for doing so. Real customer feedback is the life blood of an agile team. Small course corrections make a big difference in the final destination, so demo new features as soon as you can. Don’t try to impress by piling them up in a heap.

If this were a sermon I would need a third point but there isn’t one. If you can talk to real customers and show them a rapidly evolving version of what they want, you win. It’s that simple. And it’s that hard. It’s hard to identify the true voice of the customer when everyone wants control. It’s hard to overcome the fear of shipping when egos are on the line.

Ok, maybe there is a third point: Believe. Have faith that with a combination of transparency and excellence, you can give your beloved customer valuable software in an atmosphere of mutual trust.

Photo credit: Rutkowski Photography via / CC BY

Why I Never Work Behind IT

The phone call was from an old friend of mine who runs the IT department of a small but growing company. I was glad to hear from him and after we exchanged pleasantries I promised to help him however I could.

His company is approaching Spreadsheet Suffocation and needs a custom solution built or perhaps guidance on buying one that they can configure to deliver information to a growing customer base.

Red Flag #1 – An IT driven software project.

Small companies tend to do this — they assume that anything of a technical nature should be routed through IT. But IT people tend to look at things as puzzles first – problems to be solved. Business people, on the other hand, will first ask if the problem is worth solving. And they will quantify what the solution is worth. Once you know what something is worth to you, you have a budget. This kind of clarity rarely comes from IT.

I asked, as I usually do for a catalog of the Inputs and Outputs of the current system. This is a technique for quickly gauging the complexity of an information system. A week went by. Once I got the spreadsheets, I had a few quick questions. Another week went by before I got answers.

Red Flag #2 – Communication is a Low Priority.

If you need something and want progress made, it only makes sense that you will make time to provide materials, answer questions and accelerate the conversation toward a solution. If, on the other hand, the solution isn’t really that important, then by all means, take your time. I get it. You already had a full-time job being an IT person before this allegedly ‘urgent’ need popped up.

Peppered in among my other questions was this innocuous but significant query: Who will I talk to about the business process – the person who actually does the work and needs the new solution? Answer: “That will be me for now.”

Red Flag #3 – Insulation from the Real User.

Have you ever heard of a plumber trusting the homeowner’s measurements for laying pipe? How about an electrician using the office manager’s estimate for how many amps a circuit should carry? Of course you haven’t. But somehow, in the world of software, people who are not trained to gather software requirements presume to do just that.

Oh, they always have a reason. This time it was, “That would just cause more confusion.” (I didn’t say it was a good reason.) No software professional will ever be comfortable drawing up a blueprint based on secondhand information. It’s just dumb. Be the sponsor, be the cheerleader, be the approver, but don’t be a conduit for something the quality of you are not trained to judge.

The No-Win Project

I could spin up an effort to make my friend happy, write a document that collects bits and snatches of second-hand requirements, written over a month of catch-as-can phone calls and emails with my busy friend and finally submit a swag proposal loaded with caveats. The truth is, however, that this project needs two things to even get out of the gate:

  • A business sponsor
  • A customer liaison (not from IT)

Without these, the project won’t have a budget, won’t have priority and won’t have requirements that are on-the-nose accurate to the customer need. Without those things in place, what’s the point?