Butts in Seats: Part Duh

Several eons ago (i.e. December 2019), I wrote a post called Butts in Seats that made the astounding claim that the whole business of having people come in to a shared office five days a week for at least 9 consecutive hours (don’t give me this 8-hour day bullshit) was over. Done. Finito. Old news. In fact, I called myself a dinosaur for having a residual fondness for the butts in seats concept. Well ..

Technical co-founder looking ahead to the future of work in the Cretaceous Era.

From: Rex, T.
To: Civilization Steering Committee, Ranking Member/Theropods
Re: Our way of life

With respect to some of the recent environmental changes, some of the other theropods and I think that learning to live in holes in the ground might be a good idea. It’s clear from the KPIs that business is down slightly. With searing hot glass particles raining from the sky, tsunamis wiping out the coasts and wildfires sweeping the earth it’s become much more difficult to carry out our daily, keep-the-lights-on business out here in the open never mind starting any new lines of business.

Some ideas we already came up with – we could make shelters out of the deadly, searing hot glass particles. We could work by the light of the wildfires. Not ideal, obviously, but on the plus side, there’s lots of attractive new oceanfront property to build on.

We propose forming a committee to look into it. Might take a few millennia to get a good start on it, we’d have to do a pilot project, gather some metrics. We’ll need representation from all departments, yes even the sauropods. I know they’re slow but what are we going to eat if we don’t bring the sauropods, right? We acknowledge that selling this to the pterosaurs and icthyosaurs will also be problematic. It will take some time.

Let me know what you think. No rush. We’ve ruled the earth doing things this way for 150 million years and that’s not likely to change anytime soon.

T. Rex

Butts in Seats

I’ve always been a big fan of face-time. Not the Apple messaging app but the concept that people who speak face-to-face are exponentially more productive than people who message in “other ways”. The idea that a group of people working on the same product should be in the same room most of the time. Whiteboarding, non-verbal communication, hallway conversation. In other words – Butts in Seats.

Engineering manager ca 1995

Having said that, I’m also a big fan of Tyrannosaurus Rex, and they’re extinct. Butts in Seats is not yet as extinct as Sue the Dinosaur, but the writing is on the wall. Face to face collaboration can no longer be an expectation.

I do a lot of hiring, and the people I’m recruiting know all this. They know that old people like me want Butts in Seats. They also know that recruiting and retention are two of my biggest problems. So they bullshit me.

“It won’t be a problem” they say, and it isn’t … until it is and then having hired them it’s my problem, not theirs. I had one guy go so far as to ‘forget’ to tell me until after we hired him that he already had plans to move from a 5 minute commute to an hour plus commute. That caused plenty of grief and, as the defender of Butts in Seats, I ended up eating every bit of it myself.

So you hire someone for whom the commute “won’t be a problem”, but they need to do 10:30 once in a while. Of course, 10:30 once in a while becomes 11:00 three times a week which turns into “I need to wfh”. Pretty quickly a job that can often be fun (mine) has this daily corrosive edge to it where you drive in wondering who’s going to be pushing the Butts in Seats Boundary today and how far.

Seriously, what kind of a dick busts somebody for showing up a half hour late when we expect people to be available via Slack from 8AM to 10PM whether they’re in the office or not? Only the kind of dick who believes that a deal is a deal, and who has the support from his boss to enforce it. And let me tell you from experience, since everyone in a startup is a single point of failure, any support you think you have for enforcing Butts in Seats will disappear the minute it threatens retention. Your Jedi Manager skills should paper over the contradiction there.

In November of 2019, in the Boston market for technical talent, there is no graceful way of managing someone who isn’t meeting the Butts in Seats requirement (also known as the agreed upon and totally reasonable shared crossover in-office time of 10AM to 4PM).

What to do about it?  I’m damned if I know.  The tradeoff that seems to resonate with people is availability for flexibility.  If your off-hours time are available to the company, then your butt shouldn’t have to occupy a dedicated space at the company for a company-defined eight hour stretch.

Sure – availability for flexibility – fine. But that solution to one problem – availability – spawns a host of others, accountability, predictability, communication and the ever-popular productivity.

The real problem with Butts in Seats is its primacy – the idea that remote work is a perk that’s doled out to those who aren’t on the naughty list. I’ve managed groups where wfh was a perk, and it worked, but that moment in history has passed.

Butts in Seats is a luxury that startups can’t afford.

If the primacy of Butts in Seats is the problem, Remote First is the solution. Remote First is the organizational notion that online, non-face-to-face collaboration is the norm and face-to-face is the exception. You employ people wherever they are, and ‘figure out’ how to collaborate.

I don’t know how to do Remote First. I’m not even very good at Remote Second or Remote Third, or Remote Only In Emergencies. I hate managing remotes.** But I hate being non-competitive even more so it’s time to figure out Remote First.

** Updated 1/19 – struck through the hate managing remotes line so I can apply for jobs managing remotes.

The Invisible Hand Challenge, MD Style

invisiblehandDoctors give advice for a living.  It’s often pretty good advice, especially when it comes to what treatments will make you feel better or what lifestyle choices will make you feel worse.  When they venture beyond that important, but narrow, field their advice often makes you wonder if they live in the same reality their patients occupy.

As evidence, I introduce this hoary bit of Randian, free market, invisible-hand-of-the-marketplace advice for fixing healthcare that I’ve seen at least five times in the last week from people who are not fools.

Screen Shot 2018-05-30 at 11.17.23 AM

Do you see item #1 on that list?  How much will this cost?  Well good fucking luck getting any sort of meaningful answer to that question in any healthcare setting from primary care to ICU in any part of the United States.  Seriously, who writes this shit?

An Anecdote to Set the Scene

Not long ago, I was being held hostage in a very shitty insurance plan and wanted to minimize my interactions with the plan as well as my out-of-pocket.  So I made the mistake of asking my rheumatologist what the bone density scan he was recommending would cost.

If I had concussed him with a two-by-four he could not have looked more stunned.  Eventually he recovered, looked around and got the attention of his nurse and asked her to find this information for me.  I wish I’d gotten a picture of her face, but fortunately I can read minds and here’s a transcript of what she was thinking as she stared dumbfounded at the two of us:

Here are two visitors to my planet who do not know how things work here.  Fortunately, they both have miniscule short-term memory and neither one actually expects an answer, so … having wasted several hundred milliseconds thinking about this, I will now respectfully shitcan that unreasonable request and move on to tasks for which I am actually trained and capable of accomplishing.

Suffice to say, that number was never provided, but I had my revenge … I never went for the bone density scan.  Win/win!!

The Challenge

In an effort to make sure that I never hear this awful advice ever again from people I otherwise respect, here’s a challenge for all the “ask what it costs” MDs:

  1. Tell every one of your next 10 patients what your treatment (office visit, tests, procedures, scrips …) will cost THAT patient.  For 10 people, at worst you’ll have to figure out a couple of dozen numbers.  There’s a few rules:
    • You have to find it out yourself, not dish the task to your office manager or nurse as my rheumatologist did.  This a learning experience for YOU and the best learning is direct learning.
    • The answer you give them has to be an actual number, not an algorithm, range or a percentage.  Asking a sick person to solve a multi-variable equation where most of the variables are not discoverable does no one any good.
    • You have to give them the number while they are still in your office.  Remember, we ignorant patients are using this number to make a decision about treatment options and need close consultation with our physician to get it right.  If you send us away without this number you’re just driving us into the arms of Doctor Google.
    • Here’s a tip to get you started – remember to ask if they’ve met their deductible for the year.  Good luck!
  2. A month later followup to find out what it actually cost THAT patient.


You get one score per patient.

  • 20 points for a direct hit defined as getting the total number for that patient’s recommended course of action within plus or minus 20%.
  • -10 points for guessing high by more than 20%.  Remember, some number of people will forego treatment based on price.
  • -50 points for not finding a number you’re comfortable with.
  • -200 points for guessing low by more than 20%.  Remember, most of your patients can’t absorb an unexpected expense greater than $400.

So in this challenge your score as a believer in the invisible hand of the marketplace will range from +200 to -2000.  Why are the negative scores so much higher than the single positive? You’re a believer that a) the price is knowable and b) that patients MUST demand to know it in order to fix our fucked up healthcare system.  From a patient perspective you, the doctor, should get ZERO points for knowing the price of what you’re selling.  Beyond that, healthcare is different.  Success is status-quo-ante, failure is pain, bankruptcy and death.  Deal with it.

If your total score is less than zero, your invisible-hand-of-the-market ask-what-it-costs advice is bullshit and you have to stop saying it.

My Prediction

No one will admit taking up this challenge.  Those that poke around it will find quickly that the the money that changes hands in any particular US retail healthcare transaction is not any more knowable than the current state of Schrodinger’s Cat.

Post your results in the comments.


Epic Multi-hatting


The author, multi-hatting as engineering manager and product owner

Multi-hatting is a fact of life in organizations of any size.  As long as you remain aware of what hat you’re wearing at any particular moment, life is good, right?  I’ve said as much myself.

When I talk about knowing what hat you’re wearing, I usually mean it in the sense of knowing whether or not you own the outcome, or are simply a stakeholder in someone else’s outcome.  Sadly, knowing who owns the outcome isn’t enough to do the job well.  Different roles have different outlooks.

A typical multi-hat in many organizations, large and small, is engineering manager and product owner.  Need a product owner for a team? Slap an engineering manager in there – we pay them a lot, they know the product and the team and have a little broader outlook than the troops.  But what happens when they start managing a backlog, in particular writing epics?

In the course of managing backlog – writing stories and epics – I’ve bumped up against the “what is an epic” question a lot, especially when backtracking from story to epic.  I’ll think about the story one way and infer the epic from it, create that epic, then later realize that it fits another epic that looks at the story entirely differently.  An analysis of the epics in question split them into two very clear categories – stuff I write when my head is in the code and stuff I write when my head is in the backlog.

Let’s take a real-life example from the Dog-Food-Diet series.  We want to remotely control multiple 120VAC lights and I wanted to start work on a single story called “turn AC outlet on/off”.  It was not part of an epic.  So I scanned the list of epics, didn’t see the right one and promptly wrote an epic labelled “Controllable power strip”.  Typical engineer-think – leap to the solution and generalize.  That epic describes a thing that we’re not intending to sell – a controllable power strip – rather than the intent we’re trying to accomplish within this product which is to turn lights on and off.

Fortunately, as I discovered later, there was already an epic in the backlog that neatly illustrated the point I’m trying to make here – “Hand-off control of light”.  A totally different perspective on the work.

  • Epic I wrote when my head was in the code – Controllable power strip
  • Epic I wrote when my head was in the backlog – Hands-off control of light

What you see with the first of those epics is my wearing the hat without assuming the perspective.  A “controllable power strip” isn’t an aggregation of business value, it’s a real-world thing that’s kind of like the component that we think we want to build to achieve the business goal of “turning a light on and off”.

The backlog is, first and foremost, an expression of business value.  If the things in it don’t express business value then there’s no obvious sense to the order that you build them in and you’ve lost the point to the backlog.  In other words, do your backlog items describe how you’re going to build it, or why you’re going to build it?

Note on tool use:  If we’re building a controllable power strip to achieve this function it feels weird to not categorize this story as “controllable power strip”.  JIRA offers two ways to capture the knowledge that “how” we’re going to turn lights on and off is through a controllable power strip that we’ll build into the system.  You can use components, or tags.

I chose a tag for this particular example.  We have an Android Things embedded device, an API, a web UI and the physical installation itself at the component level.  If we had a team and a separate backlog for each of these, the power strip might be a component in that backlog.  It doesn’t particularly matter as component and tag are simple attributes in JIRA, not structural features.

There ARE tools that use JIRA’s component field as a structural item.  FeatureMap comes to mind.  It’s a tool that translates back and forth between story maps and backlogs.  I like the product but … it uses the component field to group stories into features.  If you’re already using components for actual components then you’ll probably end up reorganizing things to work with it.  Going back to the Dog-Food product, for instance, and its components, a story map with columns labelled “embedded”, “web UI”, “API” and “physical installation” makes no sense whatsoever.



PSA: Empty Test Suite

I’m writing this post, and tagging it with “Empty Test Suite” all over the place, because Googling “Empty Test Suite” won’t tell you what I discovered.  In fact, the StackOverflow method of debugging this led me on a couple of hours of bad adventure.

The setup:

  • Android Things developer preview 0.6
  • Raspberry Pi connected hardware
  • IntelliJ
  • JUnit tests using the AndroidJunitTestRunner

Almost all my tests (200+ at this point) are run on-device as they require hardware.  After hours of fiddling with Gradle, I get my tests, 45 minutes worth, running on the device.  Even hooked it up to the CI pipeline.

Then I went on a couple of hours worth of refactoring.  Run CI again, and bang! Empty Test Suite.

Testing started at 2:07 PM ...
 02/13 14:07:17: Launching Tests in 'com.farlo.android.bubbles.control.rule'
 $ adb push C:\Users\rodley\Documents\bubbles\Bubbles\build\outputs\apk\blue\debug\Bubbles-blue-debug.apk /data/local/tmp/com.farlo.android.bubbles
 $ adb shell pm install -g -t -r "/data/local/tmp/com.farlo.android.bubbles"

$ adb push C:\Users\rodley\Documents\bubbles\Bubbles\build\outputs\apk\androidTest\blue\debug\Bubbles-blue-debug-androidTest.apk /data/local/tmp/com.farlo.android.bubbles.test
 $ adb shell pm install -g -t -r "/data/local/tmp/com.farlo.android.bubbles.test"

No apk changes detected since last installation, skipping installation of C:\Users\rodley\.gradle\caches\modules-2\files-2.1\com.android.support.test\orchestrator\1.0.1\12d61be26b643c6413d207248660bce8f6d8b236\orchestrator-1.0.1.apk
 $ adb shell am force-stop android.support.test.orchestrator
 No apk changes detected since last installation, skipping installation of C:\Users\rodley\.gradle\caches\modules-2\files-2.1\com.android.support.test.services\test-services\1.0.1\c24c3f3ccf05dfdd86dbcd6c7a648d6c4a429178\test-services-1.0.1.apk
 $ adb shell am force-stop android.support.test.services
 Running tests

$ adb shell CLASSPATH=$(pm path android.support.test.services) app_process / android.support.test.services.shellexecutor.ShellMain am instrument -r -w -e targetInstrumentation com.farlo.android.bubbles.test/android.support.test.runner.AndroidJUnitRunner -e package com.farlo.android.bubbles.control.rule -e debug false android.support.test.orchestrator/android.support.test.orchestrator.AndroidTestOrchestrator
 Client not ready yet..
 Started running tests
 Tests ran to completion.

Empty test suite.

That error message seems pretty clear.  The test runner couldn’t find any tests to run.  To me, this said that I’d broken my build configuration – either grabbing a bad dependency, picking the wrong test runner or otherwise hosing the build.gradle somehow.  Setting up connected testing was just painful enough in those particular ways that this seemed almost inevitable.

Well, the error message wasn’t clear, or at least complete.  What happened was that my Android Application was blowing up on a simple null pointer in the onCreate and crashing the process, which the test runner, bless its heart, interprets as an empty suite.  If I had, first time out, looked at the logcat:

02-13 19:03:04.404 10994-10994/? E/InstrumentationResultPrinter: Failed to mark test No Tests as finished after process crash
02-13 19:03:04.407 10994-10994/? E/MonitoringInstr: Exception encountered by: com.farlo.android.bubbles.BubblesApp@d5f45a0. Dumping thread state to outputs and pining for the fjords.
 java.lang.NullPointerException: Attempt to invoke virtual method 'void com.farlo.android.bubbles.Cabinet.setupMonitoredDevices(android.content.Context)' on a null object reference

I would have seen that I’d written an easily fixed bit of crappe code, not a painful gradle misconfiguration.  If the tests had been running locally, not connected, the crash would have reported to the console just like the erroneous “Empty Test Suite” message, and again, the issue would have been obvious.

Empty Test Suite?  Check the logcat.

You Don’t Need a Technical Cofounder



A ferret.

It’s standard practice these days to have a weird, bearded man in your startup.  A guy you can cite when someone says something innocuous like “Everyone likes kittens!”, and you say “Well, except for Jason ….”.  Everyone nods.  Yeah, he makes the code magic, but what’s the deal with Jason and the pet ferret?

But do you really need Jason?  Or put more precisely, is the value of a bearded man worth the price you pay to buy him?  I’m going to make the case today that it isn’t.  This flies in the face of the advice you’ll get from angels, VCs, accelerators and of course bearded men everywhere, so I’m tilting at a windmill that will continue to turn no matter what I say.  Left to their own devices, that’s what bearded men tend to do.


A bearded man.

Let’s say you’re a non-technical founder – an MBA or Subject Matter Expert.  You have a product idea.  The standard route to MVP is that you recruit a technical co-founder, give him half the company and he makes it happen. I enjoy this state of affairs.  As a bearded man, I need people like you to need people like me because in a just capitalist world, a guy like me who couldn’t sell fire to the Eskimos and doesn’t play well with others would starve.

To you, the non-technical cofounder, the benefit of having the bearded man on-board is that you can go deep on customer development and shallow on product development because, theoretically, your bearded man has that covered.  You do what you like, and are good at, Jason does what he likes and is good at … your path to IPO is clear.

But consider this … the base salary for guys like Jason at jobs that he can do blindfolded is 150k-250k.  The entire time he’s working for you, recruiters will be knocking on his LinkedIn reminding him of this.  And he can land those gigs without trying.  True story: I once showed up late for a job interview wearing torn jeans and a black Jack Daniels sweatshirt with the sleeves hacked off,  rocking an epic unkempt biker beard and got the job.  You have to overpay to get a bearded man and even if you do that’s no guarantee that you can keep him because it’s so easy and profitable to leave.

Consider also that really hard technical work comes in fits and starts at many raw startups.  When the MVP ships and your critical path to survival is sales and bizdev, not product development, a huge chunk of your equity, cash and mindshare may be tied up doing non-critical-path make-work because “Jason doesn’t sell”.  The more stereotypically technical Jason is, the uglier that period of time is going to be for you and the more bad decisions you’re going to make just to “keep Jason’s head in the game” or to serve his misconception that product development is the be-all, end-all.

And finally, think about how hard it really is to build the thing you want to build.  I’ve talked to dozens of non-technical co-founders over the last decade or so, and 90% of them are pitching pure execution plays – no new science involved.  Everything is work, but not everything is hard work.

You’re pitching yourself to investors as a scalable CEO – someone who can figure out when, and how much, to pay up for the things you need and when to find another way to get it done.  If you start your venture by overpaying for a technical cofounder, you’re not a scalable CEO.

What’s that “other way”?  That’s your problem.  Remember, I’m the bearded man.  I like things the way they are.  But I have seen a few different approaches that work.

Be creative.  One non-technical cofounder I know took his idea to undergrad CS classes, more than once, and had them work up versions for him.  Is this textbook, ideal-world product development?  No.  Did he enjoy it?  No.  Did it work?  Yes – he made it work.  Remember your Lean Canvas (and you have done your Lean Canvas, right?)?  What’s your unfair advantage?  If you have a way of making this happen without overpaying a bearded man, that’s an unfair advantage.

Find actual volunteers.  Non-technical co-founders scam free work from friends and randos all the time.  As a bearded man I find this annoying and, in another mood will tell you “Don’t be that guy”, but today I’m here to actually help you.  So yes, sometimes you need to be that guy asking people to do stuff for you for free.  You will be rejected a lot.

Find equity volunteers.  Face it, paying people with equity is the equivalent of not paying them at all.  That said, there are way more equity volunteers out there than you think.  And there are reputable, proven contract houses that will work for equity if they believe in the founder and the business.  The trick is in finding them and making them believe.

Pay up.  Find a contractor at someplace like toptal and pay them to do the work.  This is actually harder to manage than actual volunteers or equity volunteers.  It’s also, in my experience, least likely to succeed.  The more I think about it, the less I like this option.  I take it back.  Don’t do this.

And now, having wasted a lot of your time delivering you something you almost certainly didn’t want and can’t use, I will say what every true bearded man says when he does something like that:

You’re welcome.




Learning to Love the MVP


A minimum viable spouse – plenty of room for improvement, but cheap and widely available

At the “surprise ending” of the Dog Food Diet series we ran headlong into a situation where the product became invaluable way before we’d finished the backlog.  Without aiming at it, or even thinking about it, we’d run into the Minimum Viable Product.

When I train Scrum, I run into lots of excellent people who hate the concept of MVP.  The idea of doing a “minimum” anything is repulsive to them.  They tend to be the craftsmen among us, and their philosophy of work is that whatever they build, it should be the best.  They’re the kind of people I want building my products for me.  The “minimum” in minimum viable product is like nails on a chalkboard to them.


V = R/E

It’s useful in those cases to think of MVP differently – as Maximally Valuable Product.  Value has a numerator and a denominator – revenue divided by effort – V=R/E.  If you’re prioritizing well, there comes a time in the product’s lifecycle where the revenue you get from the following incremental releases starts to decline.  If effort remains constant the “value” of that release declines relative to previous releases.


Graph of relative value delivered by sprint on the Dog Food Diet project

In The Dog Food Diet’s Sprint 7, Scrum product ownership pushed us off the edge of this cliff really abruptly.  The team, even the Product Owner, didn’t see it coming.  But in Sprint 7 the customer said, in pretty clear terms, “We’ve got this.  We’re good.  Stop helping.”.

The market told us what the minimum viable product was. By delivering just that and  no more as quickly as we could, we built the maximally valuable product for the business.

How To Be A Startup CEO: Part 37

I’ve been droning on about Scrum (or hiding in my cubicle at athena) and haven’t handed out any righteous startup-CEO wisdom in a while so, based on a Quora query, here’s some advice for all you business types as you leap from the walled garden of corporate life into the wild world of startups.

manwithlaptopOnce you leave the corporate world for startup land you quickly discover all the things that corporate did for you that you now have to do for yourself.  Like “personal IT” i.e. the services you use and the devices you carry.  Here, from careful observation of several startup CEOs, I offer some distilled best practices when it comes to handling your own IT.

  • Keep the Windows XP laptop from your last job. Startup CTOs love Windows update.  And it’s okay if the thing crashes every couple of hours and only boots every other try, hard-reboot fixes anything.
  • Insist on leaving it just as it was so you can continue to use all the expensive Windows tools your old company paid for.  That way you can keep trying to domain-login to a network you’re not even on anymore.
  • One word: Outlook.  You MUST have MS Outlook.  Preferably the version that stops working when the .pst gets up to 2G.  Make sure to bring along that 1.99G pst file too.
  • Whatever you do, your laptop and all the programs on it must be entirely different from the laptop and programs that everyone else in the company uses.  This will ensure that your CTO never gets complacent.
  • Virus protection slows the machine down so turn it off whenever you need the machine to go faster.  Remember whatever trouble you get into, your technical cofounder can get you out of it.  After all, he’s a genius/ninja/rockstar.  You said so yourself.  Oh, and McAfee is the best – you can tell because their founder is a psycho.
  • Names are hard, and domain names are REALLY HARD.  So you need a shitload of them.  And you never know when your current startup is going belly-up so you should register all the company domain names in your personal GoDaddy account.  All DNS registrars are the same.  And keep adding domains to your personal account even after the CTO has setup a corporate account somewhere else.  After all transferring domains is easy.

If you’re one of my former cofounders and recognize yourself here, pat yourself on the back, but realize that you are not alone. Every one of these best-practices have been vetted by multiple co-founders.  In some important ways, all startup CEOs are the same.


Healthcare Stinks: The Revenge of the Shrimp

shrimpSo I have this condition called gout.  It’s manageable, as anyone can tell you, if you behave within very reasonable dietary guidelines.  These very reasonable dietary guidelines include avoiding things like organ meat like liver and brains, which is pretty easy, broccoli (seriously?) and beer (forget it).

There’s also an unwritten, but very real, rule of living with gout which goes something like “don’t poke the beast”.  In other words, because gout multiplies any inflammatory issue you might have, don’t do anything like “getting out of bed” that might inflame the joints.

So I start this new job, and as part of the initiation we go off to do a week in the woods team building.  Really not my thing, and I’m paying very close attention to “not poking the beast”.  By dinner time on the last night I’m feeling pretty good.  I haven’t gotten fired yet, my team (GO PLOWS!) isn’t in last place, and the beast snores contentedly.  And that’s where it all goes to shit.

They feed us a huge dinner at the restaurant on the top of the mountain where the views look like this:


Yes.  That really is the view.  We stomped all over the mountain all day and I’m beat and hungry.  There’s a fabulous shrimp thing on offer.  Garlic and oil.  I can’t get enough, and go back for thirds.

PANO_20170510_175311In case you haven’t guessed by now, those very reasonable dietary guidelines include “don’t eat shrimp”.  Within 24 hours my left big toe is bright red, swollen and ON FIRE.  With every heartbeat the toe throbs as if I was hitting it with a hammer.  And of course it’s my own damned fault.

Oh well, accidents happen.  I knew the shellfish restriction but because I seldom run into a situation where shellfish is the best thing on offer I totally forgot about it.  Like I said, it happens.

The usual treatment for this is to hit it with a decent dose of prednisone (steroid), slap ice on it, keep it off the ground for a week or so and once again, you’re good to go.  Sadly, rest is not an option.  In fact, this job seems, in a relentlessly upbeat way, to be determined to kill me before I even figure out where the mens room is.

First, there’s the walking tour of the campus, sprawled scenically over a quarter of a mile of low-rise brick buildings.  My cube is, of course, as far from the garage as you can get without being off-campus.  And being a big company, the first few weeks is an endless march from one meeting room to another.  While this is a laid-back place, full of dogs and such, I just can’t imagine that putting my foot up on the conference table with an ice bag on it will be well-received.  So I sneak in ice-breaks between meetings and continue to poke the beast.

And after one day in the office, we have to fly to Austin for a week of walking around.  Like I said, they’re trying to kill me.

So of course the toe doesn’t get better as fast as it usually does.  In fact, after a couple of weeks, when we’re winding down the prednisone, the toe’s only a little better but because I’m continuing to poke the beast by walking like a duck all day both knees and the other big toe are starting to get involved.  It’s clear that the usual script isn’t going to work here.

<Skip long sad story about communication and scheduling misfires within the office of my regular rheumatologist>

<Skip shorter, equally sad story about communication and scheduling misfires between my regular rheumatologist and the covering rheumatologist>

<Skip even shorter, equally sad story about communication and scheduling misfires within the office of the covering rheumatologist>

So we’re a month out from the start of this attack and it’s not fixed because I didn’t rest it enough, and I’m finally in to see a rheumatologist.  She takes a history, takes a look at the right toe where the attack has now moved and proposes a two-prong strategy: lots more prednisone (which I agree with) and potentially some colchicine but only if a blood test shows good liver/kidney function.  Cool.

It’s noon time on a Friday.  As she puts in the lab order I ask innocently,

ME: Is that gonna get done in time to write the colchicine scrip today?

HER: Oh sure, I’ll write STAT on it and we’ll have the results by the end of the day today.

Somehow, I am not reassured.  But I limp gamely across the hallway to the lab, literally 20 feet away.  The order is right there and they’re waiting for me.  What service!  The guy looks at my order and has only one question for me:

HIM: Are you getting imaging done?

ME: Huh? No.

But my spidey-senses are tingling.  This can’t simply be an idle inquiry from a nosey phlebotomist.

ME: But it says STAT there right?  That means it’s going to be done right away, right?

HIM: Oh yeah, it says STAT right here.

As I leave the lab my spidey-sense has not calmed down one bit, so I ask one more time:

ME: STAT, right?

HIM: Right

Suffice to say, one should always, always, always trust ones spidey-sense.  STAT written in that field, on that form, does not mean shit because the tests weren’t run by end of day, no results for my rheumatologist and thus no colchicine for me.  The fact that I wasn’t “going for imaging” put my sample in the “whenever” bin, STAT be damned.

So to put this in perspective, the strategy to kill off this gout attack that my rheumatologist cooked up wasn’t executed because two offices on the same Epic installation and located physically within 20 feet of each other couldn’t communicate the fact that this test needed to be run TODAY rather than next business day (i.e. three calendar days).

Even if the colchicine scrip is written on Monday, because of the way the prednisone scrip is written, it’ll be paired with 30mg of prednisone, rather than the 50mg it would have been paired with on Friday.  A tragedy? No.  Less effective?  Probably.  Completely unacceptable?  You bet.

What does all this say about anything?  Even in situations where providers and staff are on the same system, nay even within the same physical office, working as a team the most expensive health care in the world delivers a quality of service that would be unacceptable from a dry-cleaner or an auto mechanic.  I work with teams for a living, and if two of them dropped the ball like this, there would be consequences.  By contrast, I suspect that by the metrics Atrius Health collects, this episode will count as a huge success.

This slipup with the lab and rheumatology was only the last in a series of unpleasant interactions with the system (see skipped episodes above) that all illustrate the same point – providers within the same office, or across offices in the same EMR, are unable or unwilling to communicate such that what’s best for the patient actually happens.  Which proves, as much as anything can, that’s what’s best for Harvard Vanguard/Atrius Health and what’s best for the patient are not the same thing.

Full disclosure: All this sadness takes place within Harvard Vanguard/Atrius Health and Epic.  I now work for AthenaHealth.  That said, I can’t say this wouldn’t happen at an AthenaNet provider.

The Dog Food Diet: Sprint 7


This project, as it stands today, is clear proof of the axiom that beauty is in the eye of the beholder.  As a Project Management Professional looking at this project I’d be horrified at the size of the remaining backlog.  As a Business Analyst, I’d be appalled that critical features have fallen to the bottom of the backlog.  As a Product Designer, I’d be miffed that we’ve done the absolute minimum design we could get away with.  And as a Scrum Trainer and Coach I am embarrassed at some of the #scrumfail we’ve committed.

As a Scrum Product Owner, though, I’d be … content.  To understand why, we have to look at one of the recurring impediments in this project – one that really blew up in Sprint 7.

We want to be ‘hardcore’ Scrum.  The stricter you are about working the methodology, the faster you deliver value.  That’s the theory, and amidst the various #scrumfails we’ve clung grimly to it.  So we’ve kept our Definition of Done strict, which includes deployment to production.  As a result, we left 15 points undone in Sprint 7 not because we couldn’t do it, but because we couldn’t get in to production to deploy it.

Our access to production has always been limited but in Sprint 7 it was nearly completely shut off.  Why?  Because the product worked so well that we’d come to rely on it.  The value of the new features didn’t outweigh the cost of shutting down production for the time it took to deploy them.

In six sprints we’d gone from not having it at all, to completely relying on it.

Our burndown (see below) screams #scrumfail, but we’re completely reliant on the thing that got built.  That’s success.  We’ve proved the 80/20 rule of product management – 80% of the value is in 20% of the features.  What’s left in the backlog is largely the 80% of the features that provide only 20% of the value.

Screen Shot 2017-12-20 at 6.45.48 PM.png

As a team member building the product, I really want to build those features.  As a Product Manager, I really want to be able to sell those features.   But as a business, we really didn’t need those features.  Who could have known?

The business can choose to do, or not do, what remains on the backlog.  The relentless prioritization in Scrum has forced us to build first, only what is provably most valuable.  Remember in our last post – Product Management Interlude – I looked ahead and guessed we’d be done somewhere around Sprint 10?  Even then, it hadn’t yet struck me how close we were to an MVP for this product.  Yet here we are, at the end of Sprint 7 with what is needed, and nothing more.  That, to me, is beautiful.

Luke, I AM Your Father

All that remains to be done on this project, the real must-haves, is a small amount of cleanup/future-proofing, some market analysis, and a case presentation to management of the commercialization question.

So this constitutes a bit of a “surprise ending” to a series that was supposed to be about spinning up a kick-ass Scrum team and doing a project.  Our Scrum board and burndowns are still full of #scrumfail, but when the product’s done, well … it’s done.  So as the team backlog has already started filling up with ‘the next thing’, now seems like a good time to wind up this series, at least as far as following the action sprint to sprint goes.

Post Mortem

I intended this series to show Scrum in action, warts and all, on a real project.  I didn’t know how it would turn out.  There are a few things that I find notable about it.

  • My expectation was that we’d take a couple of sprints to get a baseline velocity then progress upward from there.  But it didn’t work out that way.  In the end, our velocity was all over the place.
  • I expected that, since we know our Scrum, we’d dive right in and put on a Scrum clinic.  It turned out that it took us several sprints to start doing it right.  The pull of the dark side, over-commitment particularly, is strong.
  • I never dreamed that we’d end up declaring victory this early with so many of the original stories drowning at the bottom of the backlog.  Knowing that the methodology drives that phenomenon is one thing, but seeing it in action is quite another.
  • I spent a lot of time pointing out where 1-week sprints instead of 2-week probably would have helped us fix our #scrumfail faster.  That said, my opinion of 1-week sprints remains unchanged.  IMHO, 1-week sprints are just another way for project managers to steal your weekend.