Agility Starts With Sales

How many of us have had a sales rep sell us something we didn't need as a solution for a problem we needed solved and solved well. Everybody? That's what I thought. Often times, we as consumers get sold things that unnecessarily do more than just meet our basic need. Other times, we get told a product can do something when it can't. We want marketing to be enthusiastic about our software, but there are limits to everything. Better make sure marketing has actually used the system and knows what the software product can do versus what it can't.

If a product can't currently do something, don't you dare say, "We can get that to you in six months." without consulting development first. Promising things on a timeline is just setting yourself up to have to make an apology for a broken promise. What happens if your whole development team gets hit by a dump truck in the crosswalk on their way to lunch?

In a lot of cases marketing didn't relay the information wrong, they just forgot (or didn't know) that how they sold it to the consumer is just as important as what they sold. If marketing says, "You could use this product to do X,Y, and Z." The consumer is going to interpret that as "This product was designed to do X,Y, and Z." You might think, "Where is the failure in that?" The failure is that the product being able to do X, Y, and Z was probably a side effect of implementation rather than a requirement. This is only a failure if the marketeer doesn't go back to the Product Owner and say, " Hey, we really need the product to do X,Y, and Z because that is what some people are going to use it for." The Product Owner then should probably chastise marketing for selling the product outside its intended usage, but then reward marketing for extending their user base. Let's face it, products never get used exactly the way they were intended to. That's why we need to tighten the feedback loop between marketing and development. So that development doesn't fail to deliver on marketing's promises, and so that marketing doesn't bury development in overtime. Marketing is the only component of the organization with the ability to sell everybody else out of a job. In order to avoid that rather unwanted predicament, marketing needs to understand what development can deliver on. Enter the estimates.

God has a sense of humor and he hates developers

You want irony? How's this? Why are the most antisocial people on the planet in charge of improving and leveraging the most useful tool on the planet? Old school managers who used to be code jockies pride themselves on their ability to talk to things like memory and bandwith optimization and crash recovery. Time to tell the boss man to get the heck out of the kitchen. What ever happened to "No optimization before its time." Computer science types are also notorious for focusing too early on optimization. If you want to be a good developer, be of this world. Hang out in bars. Go attend a concert on the lawn. And for the sake of all that is holy, figure out what matters to real people and code to that. Try to keep the people who are out of touch with humanity from developing products intended for use from humans.

If you are on a project that takes data from everyday people, does something fancy with it and returns a result, remember to let the user interface (the code representation of the user's conceptual model) drive the engine, not the other way around.

Agile is about thinking about what we do every second we do it and how to improve.

Code with your brain on and its refinement engine engaged. If at any time, you as a developer think, "Jeez, this interface sucks." You'd better believe you won't be the only one. You should try to smooth out rough spots in your application as you encouter them. That includes sluggish performance, badly laid out interface, bad organization of control flow, etc. Theoretically the customer team should perceive these things as you are iterating and propose suggestions. I like to think "Never code alone" extends to embrace the customer team. Better to let a feature slip than to let a design hernia prevade.

When all the passengers on mothership earth throw the computers overboard, don't say I didn't warn you.

Bad efficiency can cost you execution time, bad usability can cost you your job. Over optimizing at the cost of usability is about the worst case of penny-wise pound-foolish I've ever heard of. And engineers are usually the ones that do this. This is not because they are bad people, but because they are used to thinking in terms of operational cost rather than business cost. If no one uses your stuff, you don't make any money, and it won't matter how little memory you consume, how little bandwidth your app eats up, or how secure your authentication process is.

The moral of the story is, let the product sell itself

If you keep up communications with your customer, don't make false promises, maintain a tight feedback loop with your beta testers, and put the needs of the user first, your odds of success increase drastically.