Sunday, October 09, 2016

Being Donald Trump

A lot of people are very angry at Donald Trump right now.  For the sake of our collective blood pressure -- and let's face it: as a country we really can't afford it to get any higher -- I want to help.

Being angry at Donald Trump for the things he does is like being angry at a shark for eating.  The anger that we feel is based upon an objective measure of right and wrong, what come people call a "moral compass."  Donald doesn't have this.

There is no "right" or "wrong" in Donald's world.  In his world, there are things that Donald Trump can do:
  • Grope, sleep with, and occasionally marry beautiful women
  • Build large structures, like Trump Tower in New York or Trump Wall along the Rio Grande
  • Run for President of the United States
In Donald's world, these things are good.

There are also things that Donald Trump cannot do:
  • Grope or sleep with Megyn Kelly
  • Pay for all of the work to build his large structures
  • Be President of the United States (it may take another month for him to realize this one)
These things are bad, as are all of the things associated with them.

Like the shark, Donald does the things that are good when he feels like doing them.  His world is simple and he likes it that way.  When he finds a new bad thing that he can't do, it frustrates him for a while but then he goes back to the good things and he is happy.

When he does something that you think is "wrong," your outrage baffles and angers Donald.  Why don't you want him to do something that is clearly good, since he already did it?  He can't change his behavior, because he only does things that are good, so you are wasting your breath.

In Donald Trump's world, other people aren't living creatures with wants and needs.  They are furniture.  They are there to be admired, stroked, and collected, and when they are no longer useful or beautiful they are replaced.  Donald's presidential campaign has been one long shopping trip, gathering up all of the cabinets, chairs, and tables that he will stack on top of each other to reach the presidential cookie jar.

When another person expresses feelings or opinions, Donald is confused and annoyed.  Furniture doesn't have feelings; it has cushions.  Furniture can't tell Donald what to do.

There are people who say, "He says what I'm thinking!" and you're right.  We all have a little Donald inside of us.  It's the voice that tells you to sleep with your neighbor's wife, to steal that bag of Twinkies when the convenience store clerk's back is turned, to get out of your car in traffic and bash the guy in front of you in the head with a tire iron.  Fortunately for society, most of us also have another voice -- the conscience or superego -- that overrides the little Donald, so we don't do those things.

So don't get mad at Donald when he does things you don't like.  He doesn't understand your anger.  He can't.  You can feel sorry for him if you want, but don't bother yelling.  You're only hurting yourself.

And should you vote for him?  Dear God, no!  Just as you wouldn't pull the shark into the boat, you shouldn't put Donald in the White House.  That would be neither right nor good.

Sunday, July 31, 2016

Quittin' Time

(Note: I know that this is not an easy topic to discuss, but I wouldn't be much help to people if I only wrote about happy topics.  Should Hemingway have avoided writing For Whom the Bell Tolls because it was about war?

And now you're thinking, "Did he just compare himself to Ernest Hemingway?" No, I didn't.  Well, maybe a little.  Anyway, if Hemingway wrote about quitting, he would probably say:
Quitting is bad.  Don't quit.  Unless you should.
I'm going to use a few more words than that, but that's the gist of this article. Thanks, Ernie.)

(Note 2: this is not a “Quit your job to found a startup and live a more fulfilling life” article. If you’re looking for confirmation of that decision, move along)

Every parent with a child in sports has lived through this scene: a player makes a bad play or the ump makes a bad call and the coach completely loses his mind.  His screeching voice echoes in the uncomfortable silence as parents, players, and officials stop to watch an adult have a complete meltdown over a children's athletic event.  As the ranting continues people start to wonder if they should step in or if that would just make things worse.  Eventually, the coach winds down and stalks back to his spot on the bench.  That's when the whispering begins: "I think it's time for him to quit!"

Quitting is bad.  No one wants to be a quitter.  We prize perseverance and make heroes of those who overcome adversity and keep plugging along.  Quitting is for the weak, those who can't take the heat and have to get out of the kitchen.  It's for kids who can't make the team and adults who can't make a difference.

But what happens when perseverance turns poisonous?  How do you know when staying the course is worse than choosing a new path?  Is there ever a right time to quit?

Unequivocally, yes.

When your job, whether it's the one that pays you or the one you do for the love of it (or both, if you're one of those mythical people who "never works a day in your life") starts turning you into someone you don't recognize anymore, that's when it's time to move on.  When you hear words coming out of your mouth and feel the urge to look behind you and see who said that horrible/stupid/cruel thing, you need to spend some quality time away from that job and decide if you should ever go back.  And sometimes, even when you're still enjoying yourself, the looks in your coworkers' eyes will tell you that they're wondering why you're still hanging around.  Then it's time to hang up the metaphorical cleats and look for a new career.

In other words, when your presence is doing more harm than good, you need to leave.  Here are three signs that it's quittin' time.  Do any of them apply to you?

You've gone from hero to villain

Are you the person who always bails everyone else out?  When the work has to be done by morning, are you the one who always lets out a loud sigh and says, "Fine, I'll do it... again!"  This is fine if it happens occasionally, but as I've written before, no one can stay in Here Mode forever.  Eventually you get tired of saving everyone every... damn... time, and you start to turn dark.  You'll probably still put in the extra work for a while, but it goes from something you do because it needs to be done to something you do because you're surrounded by nincompoops and slackers.  The grumbling gets louder, the praise you receive feels more hollow, and you start fantasizing about how great it would be to just walk out one day at lunch and never come back.  

Won't they be sorry then!  They'll see how much you did for this place once you stop doing it!  What a gaping hole you'll leave when you walk out that door.  No, not a gaping hole, a smoking chasm!  They won't even be able to function, especially when you take that critical knowledge that only you hold and no one else can even find.  Then they'll appreciate you!

Congratulations: you've gone from everyone's hero to the Toxic Avenger.  It's time to take your talents elsewhere before you decide to hatch your evil plan and ruin everyone else's day (not to mention your own career).  But don't feel too bad about leaving: you've probably been ruining everyone's day for quite a while without even realizing it.

Here are some signs you're becoming toxic:
  • You can't find anything good about your company, including the people sitting right next to you.
  • You refer to your office as "this place."
  • You don't trust anyone else to complete even simple tasks correctly, so you either double-check their work or badmouth it when it's done.
  • You don't trust your company's leaders to make intelligent, ethical decisions.
  • Everyone around you knows exactly how you feel, because even when you try to hold it in (which may not be very often) it comes out in outbursts whenever you're frustrated (which is pretty much all the time).
Whether these things are true or not is beside the point, because at this stage the objective reality of your situation is irrelevant.  The environment you've created in your head is unbearable.  It's quittin' time, little hero.  Pack up your tools, but leave the poisons behind if you can.

You just can't even

Sometimes your body knows that it's time to quit long before you do.  Stress, even unrecognized stress, takes a toll over the long term and can manifest in a lack of energy, drive, or creativity.  When you look at that next assignment and you can't even muster the energy to look at it, much less start working, it might be time to look for a new challenge.

I'm not talking about a down day here.  We all have those occasionally, whether it's because it's raining or our kid was up all night throwing up or because we stayed up too late playing Call of Duty.  This isn't something that can be explained by sleep deprivation or seasonal affective disorder; this is a long-term fatigue that comes from your life expectations not matching your reality for months at a time.  If you're stubborn, maybe years.  It may be the deep exhaustion that comes from compromising your principles on a daily basis, saying "yes" when your heart is screaming, "NOOO!!!"  It might be something as simple as a creeping lethargy that seeps into your soul from constant, profound boredom.

Whatever the reason, it's turned you from a cheetah into a sloth and your colleagues know it.  They've watched you go from soundly beating every deadline to enjoying the whooshing sound they make as they fly past.  They've tried offering you coffee, cigarettes, maybe even considered slipping a little amphetamine into your water bottle when a big project is due.  They've gone from counting on you to working around you.  You think they haven't noticed, but they have.  They know you're done and they're waiting for you to catch on.  

So if your down days are stringing together into slow weeks, the weeks into semi-depressed months, maybe it's time to look at where you're spending most of your waking hours.  Nothing like a spot of change to put the gas back in your carburetor.

You used to lead.  Now you're just in the way.

This is probably the toughest case to diagnose, because the patient still feels fine.  He has all his skills, he has big plans for his team, and he wakes up eager to get to work every morning.  The problem is, the job has passed him by.  Whether it's because he lacks the experience to play at this level or because he doesn't have the tools to match a new reality, he's no longer the leader the company needs, and someone needs to tell him.  Someone brave.  And probably big.  And not afraid of a little verbal abuse.

I see this situation the most with growing startups.  The original leadership team is inspired, the company is expanding every day, and their market is blowing up.  But at a certain point, the people who created the company aren't able to keep it on the right trajectory.  They're still valuable, but the value that they bring seems to shrink proportionally to the size of the company.  They need help but they're too proud to admit it.

If you feel like your job has outgrown you, congratulations!  You've done well to bring it this far, but you need to recognize when it's time to step aside and make room for people with the skills and experience that are required today.  Like the football hero whose body can't keep up with his ambition any longer, you have two choices: become a legend or become a joke.  

Don't be a Favre Founder. Take a serious look at the value that you're bringing to your team every day.  Is it as much as it used to be?  Is it still enough, or are you hanging on past your usefulness?  Know when to stand aside and encourage the next generation to take it from here, even if the "new kid" is older than you, as long as she has what the company needs now.  In the name of this thing that you built, be willing to fade into the background before you're shoved aside.  Your employees will thank you.

Quitting is hard.  You wonder what others will think, what you'll think of yourself, how you'll move on and figure out what to do next.  Even thinking about quitting a job, a hobby, or a volunteer position that means a lot to you can make you feel like you're giving up a piece of your identity.  What could be worse than that?  

Not quitting when you should have.

Friday, July 15, 2016

Egoless, but Full of Pride

When we were children, the adults asked us, "What do you want to be when you grow up?"  We gave answers like, "A fireman!" "An astronaut!" or "A professional baseball player!"  No one said, "I want to be compassionate!" or "I want to be a good member of my community!" Well, there was that one kid who was already planning to be the youngest senator in the history of the United States, but even he was already defining himself in terms of his occupation.

As we grew older, we went to college and tried to find a major that would lead to a career, or at least to a good graduate school that delayed that career for a few more years.  In our sophomore years, we questioned whether we really wanted to spend our lives in advertising, or chemistry, or teaching history, and our parents said we were having an identity crisis.  Apparently, we weren't just questioning our field of study, but our very identity itself.  We learned in that moment that we aren't what we eat after all, but where we work.

Now we're settled in our offices, spending our days in meetings, jockeying for resources, establishing agendas, and generally trying to "get ahead," wherever that is.  The innocent party question, "What do you do?" resonates with echoes of "Who are you?" and the answer had better be good.  We pin our worth to our work, measuring our value by the titles we accrue, the speed with which we accrue them, and the number of people who sit beneath us on the company org chart.  We are what we do.

Where does this leave us?  Unsettled, for one thing.  If my self-image is bound up in my position, then what do I do when someone threatens it, when they don’t show me the proper respect?  I lash out, undermining them in turn and looking for opportunities to assert my dominance and restore my self-esteem.  I forget about the problem at hand and look at the situation instead, seeking ways to turn it to my advantage.  I measure my interactions in terms of influence rather than outcome.  I stop learning and I start leveraging, and somewhere along the way I stop producing.  My work, which we assume was meant to provide some benefit to the world, instead becomes a byproduct of my ever-growing ego.

What if there were a better way?  What if I could take pride in the fruit of my labors instead of my position in the pecking order?  What if I could let go of my ego and lose myself in the creative process?  What if, instead of building my own little kingdom, I focused on producing something of value?

There’s a place for pride in the workplace, but it requires a different focus to be beneficial. When we focus on ourselves, we quickly lose sight of the outcomes we were supposed to produce and turn our eyes to all of the people who are standing in our way.  When we focus instead on our work and its outcomes, we can lose ourselves in the effort, submerging our identities into the team and joining together to create something that’s bigger than ourselves.  We lose the ego and replace it with the humble pride of a craftsman admiring his handiwork.

This is why companies write mission statements: they want to inspire their employees to see their daily work as something more than a struggle for position or an opportunity to log time toward the next paycheck.  They want to create something lasting and valuable, something to which their employees can attach themselves.  Unfortunately, in trying to cover all of the things that they think they do, most companies water down their mission statements to an unintelligible list of platitudes (“Hooli: making the world a better place through minimal message-oriented transport layers”).  It’s a valiant effort, but if you find a company whose mission statement inspires you to get out of bed every morning, never leave.

So where can we find inspiration that overrides our egos and drives us from positional maneuvering to productive work?  It has to happen locally: at the team and individual level, what do you do that makes the world a better place?  What are you creating every day you can be proud of?  What problems are you solving, which lives are you improving, what work are you doing that would make you proud to say, “Yeah, I did that.”  Better yet, what are you creating that could make someone else say, “Wow, I wish I’d done that”?

My father is a realtor, and one day I asked him why he enjoyed selling houses, because, frankly, I didn’t see the appeal in spending a perfectly good Sunday sitting in someone else’s empty house instead of spending it in my own house watching football.  

He told me, “I’m helping people find a home: a place to start a life together, to raise their kids, and to grow old together.  I’m an integral part of their life story and I want to give them the best I have to offer.”

Now that’s a mission statement.

So what’s yours?  What are you doing to make the world better every day?  What’s your real job: not your title or position on the org chart, but the thing you’re supposed to do every day at the building where they pay you to show up?  Maybe it’s revolutionizing the way people communicate, or solving really complex problems that no one else can solve.  Maybe it’s helping young couples start a life together or helping large companies make better decisions about how they treat their employees.  Maybe it’s taking care of a whole department of people and giving them the tools they need to be successful with their own missions.

Whatever it is, find it.  Focus on it like Michelangelo chipping away at a block of marble that will eventually be David.  Forget about positions, authority, and social status, and just work.  Find that place of humble pride as you go about your daily mission.  

Be egoless, but full of pride.

Saturday, June 25, 2016

Paying the Piper, Techie-Style

Growth based on debt is unsustainable, artificial.
-- Jose Manuel Barroso

Debt is beautiful only after it is repaid.

-- Russian Proverb

Technical debt.  It sounds like a scary new investment mechanism that too-big-to-fail banks created after the whole CDO/credit swap/Big Short thing ended... poorly.  But it's much scarier than that.  It's the time bomb lurking in every software product, waiting for the right time to jump out and take down your newest beautifully crafted feature.  It's the source of zero-day security holes, back door hacks, and plain old everyday performance issues.  It's a fact of life for every software company and the bane of every application architect's existence.  In my office, it's also the prime catalyst for torrents of muttered (or not) curse words.  Sometimes, it even comes with a name, usually the name of the person who thought he'd found a brilliant shortcut... at the time.

So what is it?  It's old code, shortcuts that felt necessary, compromises in quality and flexibility based on ignorance or tight deadlines.  It's the code that you wish you hadn't written, or that you'd like to smack someone else for writing.  In short, it's software development's loan against future functionality.  Like Popeye's friend Wimpy, it will gladly pay you next year for two features hacked together today.  And when the bill comes due, it sucks.

So how do you keep technical debt from taking over your product?  First, you need to recognize whether technical debt is a problem that you have to worry about.  So ask yourself these questions?

  1. Do you have a software product?
  2. Do you plan to keep adding features to that product?
  3. Do you still plan to have that product two years from now?

If you answered yes to these three questions, then yes, you need to worry about technical debt.  If you answered no to #2 or #3, congratulations!  You are the proud owner of a legacy product and can look forward to many years of saying, "No, we aren't investing in this anymore so I can't add that enhancement.  Please see our list of new products and let me know if you're interested in migrating."  If you answered no to #1, thanks for reading, Mom.  You can stop now and just tell me how great you  thought the article was.

For those of us with active, growing software products, technical debt is a constant worry, or at least it should be.  Because even if you have genius architects, brilliant developers, and aggressively detailed QA testers, you still can't escape one fact: software decays.  Even perfect code, designed to account for every known variable at the time, will feel slow, awkward, and difficult to work with three years from now.  Technology moves quickly, and user expectations move with it.  So join the rest of us, Mr. Perfect, and start thinking about tech debt.

There are different kinds of tech debt, and you need to know which kind you're dealing with before you can manage it.  Let's look at these different debt instruments, in order of urgency.

1. Visiting The Software Loan Shark

Sometimes you just don't have time to do things the right way.  Whether you're working against a tight deadline (a commitment made by "Management," of course, since you would never over-commit, right?) or scrambling to fix a Sev 1 in production, you look at your code and you think, I can do this now or I can do it right.  You look around to see if anyone's watching, then you hard-code that    client-specific logic, or you wire that UI element directly to the database, because it's Friday and you know there's a cold beer waiting for you somewhere.  You walk the changes over to the architect for the code review, because this one needs some "explaining."  You tell him, "I know this isn't the right way to do it, but the right way would take another week.  And see?  I put '// *hack*' right there in the comments.  We can come back and fix it on Monday."

You, my friend, just made a visit to the software loan shark, and the vig is high.  If I had a dollar for every time a developer investigated a production issue and said, "This was a [name of our fastest coder] special," I wouldn't be writing this blog, because I would have retired.  And, of course, by that point we had built whole features around that shortcut, so it took weeks (sometimes months) to rebuild that "time-saver" so that it worked for anything other than the very specific case that Speedy Gonzales was thinking of at the time.

So, before you go in search of that beer, create a new user story to remediate your shortcut, and 'fess up in front of everyone.  It's OK to find the quick fix once in a while, especially if it makes your biggest customer or your boss's boss's boss happy.  Just don't make a habit of it, and pay it off quickly.  You don't want to get hooked on this stuff if you want to keep your job.

2. Emergent Debt

The second kind of tech debt is what I call "Emergent Debt."  This comes from a combination of myopic planning and a general lack of omniscience.  Even when you take the time to design your solution carefully, your design is only as good as your planning horizon.  If your product roadmap only extends six months into the future -- due to genuine market uncertainty or "because we're Agile, man..." -- then you have two choices:
  1. Design for what you know you'll need
  2. Guess
Either way, you're working with limited information, and you're bound to miss something.  Even with an extensive roadmap, any decisions beyond this year are, at best, educated guesses about what your customers will find valuable.  You're going to miss something.

Welcome to the land of emergent debt.  That design that was a frickin' work of ART! two years ago is now a stinking pile of shortsighted delusions.  What were you thinking?!?  Oh, right, you're not omniscient.  So stop mourning your tarnished monument to technology and start fixing it.  Ask yourself:
  • What's salvageable?  Is it still usable?
  • How much will it slow us down to keep building around it?
  • Should we rebuild or build a replacement beside the old code?
  • What's the cost of the new solution relative to continuing to work around the old one?
Once you understand the benefits and the costs, you're ready to choose a new course.  Don't start until you truly understand that balance, because some code, even if it's old, can still do its old job just fine for years while its younger siblings steadily grow up to take over its functions.  Don't jump into a rewrite just because you're offended by your younger self's myopia.  Write the user stories, put them in the backlog, and prioritize them against the new features that were already there.

3. Code Decay

Even high-functioning code gets old, and sometimes you have to replace it, not because it isn't extensible, but because the rest of the application has passed it by.  Code written for different hardware configurations, leveraging ancient libraries, can become a bottleneck or even a source of crashes when faster components start racing through their actions before waiting for the old-timer to hobble through its logic chain. Like a 1964 Maserati in a world of Teslas, your code is still beautiful, but it's getting expensive to keep around.  Time to upgrade.

The good news is that this is a chance to learn from the past.  Study the old code, see what it does well (if slowly) and what pieces you had to write because they didn't exist in the developer kit yet.  Look for opportunities to leverage and extend a clean design and then rewrite it with half the lines of code.  Look for performance upgrades so that the new version can last for another several years and cause bottlenecks in other places before it needs to be updated again.

You often see code decay early, so you have time to plan to replace the old code.  Put the user stories in your backlog and keep an eye on the current code in production.  Since these rewrites can often take some time, make sure that you start the work before it becomes an emergency (see: Loan Shark).

4. Moronic Predecessor Syndrome

This category may or may not represent actual technical debt, but in my experience it creates the most noise in every software organization.  I call it "Moronic Predecessor Syndrome" (MoPS for short).  Here's how this works: the smart developer that you just hired a week ago walks up to you in the hallway and says, "Whoever built this component I'm working on was a complete moron.  We'll have to rewrite the entire thing."

You reply, "Hmm, he seemed pretty smart for the 4 years he worked here.  Why do you say that?"

He replies with a series of beeps and clicking noises that in reality are English speech, but you've stopped listening because you've had this conversation before, every time you hired or promoted a new developer.

You see, developers are smart people who thrive on complexity and problem-solving.  I've kept brilliant teams working together in stultifyingly boring industries simply because the problems were interesting (the secret is to keep feeding them problems at the proper rate so they don't notice that no one understands what they do).  Sometimes, though, this problem-solving tendency runs out of control, especially when a developer is bored or feels a need to prove himself, as when he enters a new role.  This is where MoPS rears its ugly head, and you have to decide if you're facing a real problem or an aesthetic difference of opinion.

Once the beeps and clicking noises wind down, try asking a few questions:

  • Why do you think the code is all wrong?  Is it functionally deficient or is it built "the wrong way?"
  • What's the impact of the current design?  Is it slowing us down or making it difficult to add new functionality?
  • Does the rest of the team who works with this code agree with you or are you the only one seeing this? (Try to avoid using the word "visionary" here: it will sound sarcastic).
  • How long do we have before the problems you foresee come to pass?
Note that I didn't ask, "How long will it take to fix this?" because the answer is inevitably, "6-12 months."  Seriously, every time.  I have never seen a breakout of MoPS with less than a 6 month price tag, so before you even go down that road, make sure that you're dealing with a functional issue and not a difference in technical tastes.  If the issue is aesthetic, bring some other people into the conversation to talk about how they make this grossly disfigured code work for them.  Offer to look at alternatives in the future, but don't waste time rewriting functional code just because someone thinks it's ugly.

If you determine that you do have a problem, then follow the same steps as for Emergent Debt: assess the risk, understand the cost and benefits, plan the work.

And did I mention that you should create a user story?

Paying Off Your Debts

Development teams get weird when it comes to paying off their technical debt.  There seems to be this shame attached to fixing old code, as though the company should have known better and written code that would stand the test of time.  Yet tech debt accrues in a myriad of ways, and as long as you aren't making weekly trips the software loan shark, you don't have anything to be ashamed of.  This is life in the digital world, so stop trying to sneak your debt payments into your new feature estimates!  (And yes, I know who you are).

Eliminating technical debt is just like any other piece of work: you're investing to improve your product, and you expect certain benefits from doing the work.  Just because they're often invisible to users doesn't mean they don't exist, and everyone wants a product that stays usable over time, right?  Of course, you can't blackmail the budget keepers with "do this or your precious site will crash," so you need to make your case.  New features have business benefits (new revenue, increased customer satisfaction, competitive advantages) to offset their costs, so why aren't you doing this for your technical debt?

Here's how the conversation usually goes when a developer wants to fix old code:

Developer: "We need to fix this."
Product Owner: "Why?"
Developer: "Because old code sucks and the new code will be better."
Product Owner: "Shut up and go build my new feature."

What if, instead, we created a business case for out debt payments?  All you have to do is quantify "better."  If spending 4 weeks building a new service means that the next 5 features can be built in half the time, that's obviously a good investment.  If rebuilding the calc engine means that our product stays performant for another 3 years, that's probably also a good investment, assuming that it doesn't take a year to build.  The question behind every business case is simple: how can you make the benefits quantifiably outweigh the costs?  And since costs are easily measured (people * time = $$$) the more quantifiable the benefit, the better.  If you tell me that you can guarantee that a $10,000 investment will return $100,000 in the next year, I'd be an idiot not to take it.  If you tell me that you want $10,000 so you can make something "better," then you're asking for a lot of trust.

And if you can't quantify the benefit?  Then you probably have a bad case of MoPS.  Take two beers and a good look in the mirror and call me on Monday.

Monday, June 13, 2016

In Defense of the Plan, Part 2

I wrote recently about the need for long-term planning, even (perhaps especially) in an Agile development environment.  I left you with a choice: plan or fail.

The fun part about writing on the internet is that you don't really have to solve problems: you just have to point them out so that other people can agree with you that yes, there is a problem there, and someone should do something about it.  I'm a problem-solver by nature, though, so I can't just leave it at that.  If I'm going to tell people they need to do something, then I'm constitutionally required to help them do it.  So we've already covered why you need a plan for your product development.  Let's talk about how.

Let's start with a few objections, because I never met a straw man I didn't like (to poke holes in):

  1. I can't tell you when we'll have a whole feature set done because we're using Scrum/Kanban/Lean Agile/some other Japanese-sounding development process.
  2. I can't plan because I don't know how long it will take to build something six months from now.
  3. I can't create a release plan because I don't want executives to see it and think that my team has committed to specific deliveries way out in the future, where all the uncertainty lies.
Let's take these in order:

1. Your development methodology doesn't matter.

I hate to break it to you, but no matter how proud you are of your particular style of software code widget management (i.e., your methodology), it has no impact on your ability to predict what your team can accomplish over the long run.  You see, that delivery method is the micro view, and the little irregularities that can torch a sprint or a Kanban board in the short term all even out over time.  Release planning, on the other hand, is an exercise in macro planning that's almost Seussian in its simplicity:

I have this box.
I have these rocks.
How many rocks can I fit in this box?
It's somewhere between a little and lots.

(For those who prefer allegory over metaphor, rocks = major features, the box = your release)

Individual vacations, surprisingly difficult features, requirements changes, these are all daily problems that have no place in the long-term plan, and using them to keep you from looking at the  big picture is either laziness or a misunderstanding of the viewpoint.  Think in big chunks, average velocities, and conservative predictions and the picture will quickly clear up.

Ask yourself:
  1. How much time do we have to build this release?
  2. At a rough order of magnitude, how long will it take to build each major feature that we want to include?
  3. How many of those major features can we get done in the time we have?
Ta-da!  Instant release plan.

2. When you estimate has little impact on what you estimate.

There's no doubt that development teams learn things as they build that make their estimates more precise and their designs more accurate, but claiming that you can't estimate a feature now because you plan to build it later is a fallacy.  How do I know this?  Reorder your product backlog and move those features to the top of the list.  Go ahead, I'll wait....

Can you estimate them now?  That's what I thought.

I understand that there's complexity here.  What if one feature depends upon another?  What if building that framework first makes it easier to build all the features that will use it?  What if your customers decide that they want another feature that isn't on the list?  These are all things that could be true and might change your project.  But how many of them actually impact your estimates?

Sometimes development teams become infatuated by complexity. Like that pretty girl you can't stop thinking about, they see it everywhere they look. But sometimes it's just a skinny dude with long hair. Rather than making a long list of the things that could happen to blow up your plan, how about making a small list of reasonable assumptions that will help build your plan?  Assume that you'll be smart and build the framework first, then estimate your effort based upon its existence. Build a plan based on what you know now rather than waiting until you know everything (hint: you never will).

3. Learn the difference between planning and presenting

Above all, your release plan is for you.  It's a guide and a goal for your team, helping you understand how long you have to build things and when it's time to move on.  It helps you shape the picture of what this thing is that you're trying to build and, most importantly, what done looks like.  If this were a road trip, your release plan would be the map that tells you whether you're driving to New York or Hawaii and helps you choose the destination with the highest likelihood for success.  Along the way, it also helps you set intermediate goals, plan your next steps, and ensure that you don't wander too far off the path chasing shiny objects.

Your stakeholders, customers, and whoever is funding your project (read: executives or investors) also want a hint as to what they'll get for their time and money, and this is where presenting comes in.  The smart team lead knows how to set achievable targets that account for the risk inherent in software delivery, then hit every one.  Some people call this "under-promising and over-delivering."  I prefer to call it "risk mitigation and expectation management."  Of course, you can't mitigate risks if you haven't identified them, and you can't manage expectations if you don't know what you're capable of delivering.  In other words, you need a plan (and if you didn't see that coming, you really haven't been paying attention).  With the plan you've built for yourself and your team, you can easily account for the estimates that feel accurate but make you the most nervous or for those parts of the product that present the highest levels of uncertainty in execution.  Build contingency into your plan and commit to exceed expectations whenever possible.  I like to set stretch features in every iteration or release, giving my team room to deliver everything that we've promised, even if we hit some bumps, then give our users a little more when things go as well as we'd hoped.

In other words, if you're confident that you can get to New York in the time allotted, tell your executives how fabulous Cleveland is in the fall, then try to surprise them with a trip to the Big Apple.

Why Plan?

This still feels like a lot of work, so why are we doing it again?  Because:
  • It sets the expectations for your team and help them understand what they'll have to show for all the work they're about to do.
  • Like the framework of a building, it provides a rough guide for where every feature goes and how long it should take to build it, helping you identify the most efficient path to completion.  When features get too big, it warns you before they take over the project.
  • It helps you identify risks and opportunities before you stumble across them, that you can mitigate them or take the best advantage of them.
  • It lays a foundation for communicating to everyone who cares about your product -- and the more people who care, the better, no matter how annoying they may be -- and helps you manage expectations and chart your progress.  This is a significantly better approach than saying, "We'll tell you when we're done," an approach that has never in the history of time failed to aggravate the people with the money and always leads to more bad attention, not less.
So forget what your Agile guru said: the sprint is the means, not the end.  Sit down with your team and contemplate your glorious future together.  It starts with a simple question:

"Does anyone know where we're going?"