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!

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica