Filed under Exceptional Software

(mis)Communication

As one who talks about being exceptional and delivering exceptional customer experience, it saddens me to say that I have committed one of the most common customer service missteps. Assuming.

A client gave me some information and I assumed it meant the deadline was no longer as hard-and-fast as originally communicated, so I took my foot off the gas and coasted to the finishline. Only to find out I was wrong. And my client was looking bad to their client which was all on me.

I was blissfully and ignorantly going along. There was no communication through this time that my client was unhappy, and no news is good new right? Wrong. They were not happy, and were stewing over it while I was completely unaware.

We are all human and in the stress and hussel of business it is too easy to take the easy road on bad habits. Regular and deliberate communication in imperative to success. And always remember the old adage: You know what happens when you assume…

Why the web software industry is broken

My recent renewed focus on consulting with Foolish Software has lead me to a very disturbing conclusion. Web software development, particularly in the consulting space (but not exclusively), is broken.

If you think of a software as a car, it has many moving parts (an ever-changing selection of parts no less) and is bound to break down or need maintenance at some point in its lifetime. What’s worse is that it’s not a production car but a custom built machine. So when the creator goes out of business or moves on (which is usually fairly quickly) you are left with something that any mechanic can understand conceptually, but the specifics exist only in the head of the original creator.

A car is easier to quote accurately; you have certain parts at specific prices, and the labor is fairly predictable. So if someone asks for a Porsche for a Toyota price it’s easy to say no. It’s also easier for the consumer to understand why they can’t get it.

However, in software it is not uncommon for people to ask for the “Porsche” at “Toyota” pricing and if they are willing to sacrifice quality they can probably find some consultant whose price is low enough that they might get it. Or at least get what they naively believe to be it.

This is because the average consumer of software development services can’t comprehend the difference between quality workmanship in software versus a hack-job. And in some cases the hack-job is good enough.

But let’s assume that quality vs price is not a real problem. Which it is, but many people will argue with me that good enough is just enough and that you deal with the other problems later. But for the sake of argument if it isn’t a problem, software development is still broken in one more profound way.

Development is mostly looked at as a transactional service and not a partnership. This is probably the biggest area of concern. When software development is transactional, the client has a budget that usually only covers a portion of the initial development costs and little else.

The salesman working the deal needs to close, so she manipulates the finer points. No paired resources. Simplest possible solution (which often is just lip service, and code for “we’ll cram it in somehow”). No testing. This leads to cut corners, no predictability, and zero documentation.

If you cut corners at the onset, it may run fine for a while, but eventually, when people actually start to use the software in a meaningful way, its deficiencies make their way to the surface, and the initial developer is no longer around.

Nobody has kept the code up-to-date or optimized anything. Back to the car analogy, nobody has changed the oil, rotated the tires, or fixed the breaks. So what happens? Breakdown, crash, panic mode, and draining expenses to fix it.

Unfortunately, the industry is built around this transactional model and is very difficult to break. Established companies have the best chance at breaking out. They have a reputation and a bankroll to allow them to be selective. To be willing to say no the bad customers and have enough momentum to attract the good ones.

A new company just starting out is trying to pay the bills any way they can. They take the crappy work knowing the damage that is likely being done, in the hopes that they can get enough business to break through that ceiling. It rarely happens. And thus there will always be crap work to grease the gears of the endless cycle.

What can be done then?

If you are a company looking to hire developers or consultants, think about how you plan to maintain things a year or two out. What will happen when your team goes away? Is the software important enough to do it right? If so, remember that software development never ends. If your business relies on custom-built software you will always be working on it.

If you plan to offer software development consulting as a service, do right by your customers. Price it right. Include everything necessary to set your customers up for success and don’t bend. Delivering crappy software for a few bucks is not a sustainable business model and while customers may say they’re OK with cutting corners, they are lying.

When the software breaks, they will call you, and you will find yourself spending weeks or even months of non-billable hours fixing stuff they agreed to neglect. Because after all, they agreed to cut corners, not to non-functioning software.

Acceptance Criteria That Doesnt’ Suck

It’s planning day, so today seemed as good as any to post about good AC.

Gathering Acceptance Criteria, or AC for short, may be the most critical component to a successful sprint. Unfortunately, it’s a predictably regular occurrence to start a sprint and somewhere along the line, the product owner finds some additional complexity or use case that doesn’t fit the planned implementation. It is also often that the product owner will not sign off on the work while the feature does not meet these newly defined expectations.

At this point, you have two choices. You can let them add this AC mid-sprint (which of course is a major no-no), or you can talk them into making a new story and then go through the hassle of explaining that this new functionality is out of scope and that they will have to de-scope some other feature blah blah, nightmare!

Anytime you discover new things during a sprint you are making your life progressively more difficult. And ultimately you are setting your project up for failure. Get it right the first time!

If you are doing TDD or at least writing cucumber tests, think of AC as a set of scenarios. The more specific the less missed AC there will be. Cucumber scenarios follow a simple pattern.

  • Given (State)
  • When (Action)
  • Then (Result)

You can have multiples of each in a scenario, but the pattern remains: given a set of criteria, when I do some action, I should get some result.

Here are some examples:

  • Given I am on X page. When I follow Y link, then I should see something.
  • Given I am on Z page. When I select “date” from dropdown list, then it should re-sort results
  • Given i am on the login page. When I fill out the login form with my email and password, then I should see the dashboard page and a welcome message.

They don’t have to use the exact language of a cucumber scenario, but using the basic formula will lead you to further questions and discovery.

In order to not waste a bunch of time in planning, be sure to work with your product owners to do their part and come to planning meetings with AC prepared.  But don’t be surprised when you have to hold their hand through it the first few times.

If the scenario is not immediately evident, or if the customer is unusually difficult, here are some AC discovery questions. This is by no means exhaustive, but we can add to it.

  1. How do I get here?
  2. What does it look like?
    • what should I see?
    • what should I not see?
    • potential options and outcomes?
  3. What happens after?
  4. Who will use it (major feature or edge use case)
  5. What can we do to simplify this?
  6. What would happen if your users did not have this feature?

Agile Product Management – It’s Real!

Product management is a dirty word in Agile software development circles, and I am baffled by this blatant omission. Considering that most people have no idea what it is, the resistance is due to ignorance and/or fear, more than a disagreement with the philosophies or methodologies of it.

Agile is incomplete without product management. As I see it, the intent of the agile methodology is to allow for emergence in the development process. But in order for emergent phenomena to occur, all participants must have two basic things; a clearly defined common goal, and a set of guiding principals by which they can evaluate all decisions.

This is precisely what product management is about.

Most of the skeptics are already rolling their eyes. I can see them. But I present to you a minimalist version that you can start implementing now and see for yourself if it’s an idea worth further exploration.

Before I start, if you are not having a kickoff meeting for new projects, you should stop reading this now and seriously reconsider your career choice.

If you are, start your meeting with these four questions to set the target. This way everyone knows what the goal is and the constraints they are working in. Constraints are very important. Knowing the constraints will help you know where the client will be willing to compromise to achieve the goal.

1. Why are we building this, and what problem are we solving?
This is the goal setting part of the process. Be clear and concise. A goal needs to be easily repeatable and easily understood by someone unfamiliar with the product.

2. Who is it for: Primary Audience? Secondary?
Define a very loose profile of your primary user, and if necessary the secondary user as well. The primary user is most important, and should be considered first in any overlapping use cases.

3. What is important to that audience?
Considering the user profile, what kind of things would be important to them when using your software. For example, if your primary user is elderly, they may require large easily readable fonts and simple structure. If they are 20-something it professionals it should be customizable and accessible via an API.

4. What are the constraints?
This can be anything that constrains the development of the product. It can be anything from browser compatibility to fixed budget. Money is usually the most common and most obvious, but other constraints could be accessibility, timeframe, or competitors.

Questions 2 through 4 combine to form a profile of the criteria you should be using to evaluate every decision that you make in support of your goal.

This is a very basic start, but it should help you to see how product management can help you deliver exceptional software.

Follow

Get every new post delivered to your Inbox.