Skip to main content

In Defense of Mortgage Driven Development: That's Our Target Market, You Goofs!

I was speaking with a group of fellow would-be agile change agents last week, and one of us described "the opposite of agile" as "mortgage driven development."  Of course I found this funny and apt, and I looked it up online, where I found Jason Gorman's tongue in cheek manifesto for the MDD movement online:
We are uncovering better ways of making money from
software by doing it and hindering others from doing it.
Through this work we have come to value:

Timesheets and invoices over principles and ethics
Unmaintainable software over clean code
Contract renegotiation over a barrel
Unlimited overtime over a sustainable pace
Contracts that fall outside of IR35 over and over again

But as I reflected on the matter, I realized I would prefer to describe the above manifesto in terms of "Marauder Driven Development" instead, if we must have a straw man abbreviated to MDD.  Our enemy isn't mortgage-holders with their desire to maintain a stable family home, or even normal climbers of the corporate ladder who are most concerned about hanging on to their maid and their boat.  The real enemy is the kind of arrogant short-term thinker who lives in corporate housing and doesn't even unpack her bag, except to send wrinkled clothes to the dry cleaner.

Unlike, say, the phrase "mortgage-backed securities," "mortgage" is a word with strong emotional pull and a relevance to real people who think in terms of life-long responsibilities, careers, and families.  "Mortgage-driven people," loosely defined, are our our best agile allies, and their similarities to the marauders implied by the MDD manifesto are quite superficial.  They do not deserve our scorn!  Scorn at the "mortgage" orientation implies that "real agile" is too proud to consider money making, because it is focused somewhere unsullied by the profit motive.  Turning our noses up at money is all well and good, but that attitude and a dime (and a time machine) will buy us a cup of coffee.  Our richest target market segment, if we intend to make money by being self-identified agilists, is "Mortgage Driven," and there's no point in alienating these people unnecessarily.

Why do companies hire us? 
To spread credit (and especially blame) fairly, I must say that this is a question I was privileged to discuss with Jake Calebrese, Russ Miles and Ahmad Fahmy last Friday (follow their blogs!).  One thing we agreed was that if we want to figure out how to change the world through value-driven agile techniques, we have to recognize that we aren't hired by companies.  We are hired by people.  So railing in general against "the machine" isn't a practical marketing approach.

Since we are hired by people, we need to understand how to to motivate them, as Aristotle would say, in terms of logos, pathos, and/or ethos:  logic, emotion, or social pressure.  Or as Dan and Chip Heath would say in their book Switch:  How to Change when Change is Hard, we need to motivate the rider and the elephant, and we need to prepare the path.  (Read the book!)  Okay, you say, then:

Why do people hire us?
The moral awesomeness of agile isn't enough for most people.  "Awesome" doesn't overcome people's even deeper allegiance to "avoiding change."  Picture this in terms of Maslow's hierarchy of needs:

From:  http://commons.wikimedia.org/wiki/File:Maslow%27s_hierarchy_of_needs.png
A client who is can be motivated by our moral disapproval is unlikely to show up waving her checkbook at us for several reasons:
  • This person would be coming from the very top of the pyramid, not, perhaps the most populous segment to pick, if we're picking one.  Look at the pyramid and compare it to your life experience.  How many people with true profit and loss responsibility make decisions first about morality or the respect of others in complete isolation from expected return on investment?
  • A person in this happy place is likely to be able to adopt agile on her own if she wants to.
  • Seriously?  Would you seek out someone who has just morally disapproved of you as a client?  In other words,
  • Such a client doesn't exist.  
Good-fit clients are doing household maintenance of some kind
A whole slew of people are likely to be interested in doing a controlled agile transformation over 3-5 years because they think they might otherwise be standing on a burning platform in the foreseeable future.  Perhaps they have aging infrastructure they want to replace in an orderly way.  Perhaps they are concerned about a trend towards increased regulation, and want to avoid future surprises.  Perhaps they are "ripe" to be promoted to the next level in the hierarchy in a year or two, and they want to show off.  They're intellectually curious about agile, they are thinking about the future, and they're also powered by the understanding that even though their platform isn't burning, maybe it is smoldering.
Our "best fit" clients are motivated by mortgage-style concerns.
Our most promising potential clients are people with a genuine problem to solve which is the emotional equivalent of "if I don't do this, how will I pay the mortgage"?  They would include corporate employees who have responsibilities to fulfill and choice about how to use their money to fulfill those responsibilities.  The agile metrics story is logical to them, but the emotional appeal speaks straight to the "fight or flight" impulses in their brain stems.  They have some kind of burning platform:
  • Continued employment requires a change:  These people need to improve their metrics around quality, speed to market, transparency, and customer satisfaction annually or else.  The "S curve" will eliminate them if they are a "bottom performer."  "Not moving forward" is the same as "fired" for these people.  And then how will they feed their children?
  • Continued viability requires a quick release to market: a person may develop a sudden and unprecedented interest in agile if she is facing a normal software development life cycle that takes 12-18 months, but she has a 3-6 month opportunity to be first to market with a new product, or even to be a fast follower.
  • Continued reputation and hireability into the next job requires a project to be rescued:  if all else fails, try something new, our prospective client may feel.  Better to be agile and succeed than do business as usual until one is requested to fall on her sword.
I guess in Japan it might have been a real sword even quite recently, but in most 21st century cases today, even if the sword isn't real, our best potential clients have an emotional aversion to it which goes quite deep.

Either way, the point is that most of the visceral, emotional energy that leads to an initial engagement can be described beautifully by the words "mortgage driven."  It's about making money, but unlike other candidates like "Cash Driven Development," say, or "Loot Driven Development," or maybe "Pillage Driven Development," for me, "mortgage" brings to mind people here in the the US over the past few years who lost their homes when they couldn't afford their payments, or people who are grateful every day that they were able to keep up.  So if that's Mortgage-Driven Development, sign me up!

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…