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:

PANO_20170510_175311

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.

In 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 5

superman-1275374_1920Sprint Goal: At least one control-function installed and working within physical element and more sensors reporting actual values.  Until now the embedded system has been reporting values to the web, but not responding to commands from the web.  Now we want to largely complete the reporting function and implement one instance of the control function.

Sprint Planning: Backlog was in good shape, our velocity was 40, we took 40.

Sprint Review: We showed one control-function working within the embedded unit.  The one we chose to show was run from a schedule within the device, rather than controlled from the web because that was highest value to the PO.  The team using the system didn’t need manual control (which was also harder) but simple scheduled control.

Retrospective: Finally it all seemed to click.  We under-committed our actual velocity and finished early, way early, then piled on the wins.

Note that we burned down to our last committed story on the 11th day of our 14 day sprint, then started taking stories off the backlog without taking the last one to done.  The last story was blocked temporarily.  The sprint goal was already crushed, and we knew we’d get that last one in so we went to the backlog and ended up completing 6 more stories in addition to the last one from the commit.

How did our kaizen from Sprint 4 work out?

We more than doubled our velocity from Sprint 4.  Our official kaizen was to only commit our actual velocity, which probably accounts for some of our acceleration.  Some of it was luck/random variation.  But we think that improving our testing game, which has been ongoing and included test infrastructure stories on the backlog, probably accounts for far more.

What is our kaizen for next sprint?

The team attributed most of our acceleration to more and better testing, done sooner.  Stories that failed integration or worse, crapped out in production, sailed through both those and went straight to done.  So we chose to double down on that by trying TDD for all new code for this sprint.

We also haven’t managed to eliminate interruptions – work added mid-sprint.  No one ever does.  The cure for this is the interrupt buffer.  The average interrupt for the first five sprints has been X points so we’ll start with that.  This is something we should have been doing all along.

Taking two kaizen is not ideal.  This was driven as much by the team not wanting to wait two weeks to do something they’d already decided to do and knew how to do.  That makes it another sprint length note, again in favor of 1 week sprints.

 

 

 

The Dog Food Diet: Sprint 4

Sprint Goal: One instance of the new embedded technology running within the physical element.  This sprint goal should look familiar – it’s the unfulfilled part of our Sprint 3 goal.

download

Mirror, mirror, on the wall, what is our actual velocity?

Sprint Planning:  Backlog’s in good shape.  Our 3 sprint rolling average is (18+52+32)/3 = 34.  That’s our real, Scrum-certified velocity.  So what do we commit to?  Sigh, some habits die hard.  42 points.

Sprint Review:  We showed one instance of the new tech, running on the physical platform.  Sprint goal achieved.  We recorded velocity of 31 points.  That number looks familiar.  Hmmm, slightly less than our rolling average velocity.  Maybe we should use that?

 

Sprint Retrospective: On the plus side, we achieved the sprint goal.  On the minus side, we still added scope mid-sprint.  And we over-committed once again.  Our velocity is actually pretty stable, but we’re not getting better.

How did our kaizen from Sprint 3 retro work out?  We reduced, but didn’t eliminate, interrupts and the associated context switching waste.  We managed, despite losing significant capacity, to maintain our actual velocity of 30+ points.

Our kaizen for next sprint?  Commit to our actual velocity.

The Dog Food Diet: Sprint 3

Overcrowded_ferry_boat_on_Meghna_River,_BangladeshWhen the home team wins a game they’ve played poorly, the announcers often describe it as “not an artistic success”.  That’s how I feel about this project right now.  Like the overloaded river ferry on the right, we’re getting somewhere, but it ain’t pretty.  We shipped some water in Sprint 3.

Sprint Goal: The physical element being used for its designated task and one instance of the new embedded technology running within the physical element.

Sprint Planning: The product backlog is in good shape.  We come to Sprint Planning having achieved a velocity of 50 points in Sprint 2.  So what should we commit to in Sprint 3?  If you guessed 50 points, you’re right (sort of, see retrospective below).  We over-committed seriously in Sprint 2 despite having a known velocity of 18.  So what did we commit to in Sprint 3?  If you guessed “a little less than 50 points” you’re right.

Sprint Review: We showed an instance of [a thing] being built in the physical element
but did not get an instance of the new embedded technology running our skeleton app mounted in it.  The sprint goal was not met.  We achieved a velocity of 32 points.  More on that later.

sprint3burndownchart

Sprint Retrospective:  Anyway … we’re happy with our backlogs, which is nice, but you don’t have to be an agile savant to smell the #scrumfail in the Sprint 3 burndown chart.  We missed the sprint goal and for the third sprint in a row we achieved less than we committed to.  In this case we committed to 45 but only achieved 32.  The 45 point commitment was (marginally) defensible because we hit 50 points in Sprint 2.  But it didn’t work.  This brings us to a great sprint planning tool – the rolling average.

What would have happened if, instead of using the 50 points from Sprint 2 (the simplistic version of yesterday’s weather we should have used in Sprint 2 planning), we’d used the average of Sprint 1 and 2?  Sprint 1 – 18 points, Sprint 2 – 50 points, the average – 34 points.  Almost exactly what we got in Sprint 3.  Lesson learned.  In fact, what we will use going forward is the rolling average of the last 3 sprints.

We also backslid by adding 20 points of scope mid-sprint.  Looking back at that added scope we had a big development story, a development research story and a business research story.  The two research stories got done, the development one didn’t but they were all prioritization mistakes by our PO because they didn’t need to be done right then.

A Brief Rumination On The Beauty Of Points:  We found ourselves, at one point in this sprint, blocked on the top stories we wanted to work on.  We sat staring at the sprint backlog and somebody finally said:

What can we do to score some points today?

It took awhile, and trying to start another couple of stories that turned out to be blocked, but we found a winner and went to town.

Now, there’s nothing noble about that – as “highly motivated self-starters” we should know what to do and be doing it already.  That said, it occurred to me that there was something important exposed by this episode.  Namely, that in a non-point-based system, we would have picked something to work on, and just worked.  In a point-based system, we found the highest priority thing we could take to done and did it.

“Doing work” as we would have done in a waterfall system, creates sunk cost, that’s all.  Taking a user story to done creates business value.  And that’s what point-based accounting incentivizes – taking user stories to done.

“Scoring points” is not the way I typically think about “getting work to done”, but it’s not wrong.  If it helps you then use it.

How did our kaizen from Sprint 2 work out?  Our kaizen from sprint 2 was to keep our sprint backlog stories to 8 points and under.  In fact, we took two 8s, started but didn’t finish one, and didn’t start the other.  A wash.

Our kaizen for next sprint?  The consensus is that our velocity without interrupt-chaos would be somewhere around 40, so our kaizen for next sprint is obvious – push back on adding scope mid-sprint.

Notes on sprint length: The fact that we run 2 week sprints accounts almost entirely for the 20 points of added scope.  If the next sprint started next week instead of a week and a half from when they were added we probably could have resisted the urge to throw them into this sprint.  This is an argument for one week sprints.

 

 

 

The Dog Food Diet: Sprint 2

We scrambled for Sprint 1 and it ended up looking ugly.  In reality, we moved the product forward as reflected in the PO’s blessing of the sprint goal.  Still, we started without a sized backlog, as a result we overcommitted by 2X, and ended up with a burndown that screamed “FIRE ME”.

Sprint Goal: Physical elements in-place, able to accommodate the mechanical elements though with potentially large, ongoing manual intervention plus at least one monitoring function running (i.e. with at least one sensor in-place and communicating, somehow to the world outside).

facepalm

 

#facepalm

 

Velocity:  We achieved 18 points in Sprint 1 so what should we commit to in Sprint 2?  If you guessed 18 points, you’re right.

So what did we actually commit to in Sprint 2?  If you guessed some multiple of 18 points, you’re right again.  67 to be exact.  #ScrumFail

Review: We showed the physical space with one sensor mounted and continuously uploading two values to a PHP page on an accessible web site.  Sprint goal was achieved. We recorded a velocity of 50 points.

Retrospective: We fixed some things from Sprint 1.  Product backlog was ready, we didn’t add scope mid-sprint.  We over-committed, big-time again.  50 points is an improvement from the 18 we got in Sprint 1, but it’s not 67 which is what we committed to.  Scrum Pattern: Teams that finish early accelerate faster.  That’s what the data shows, and it makes sense even in this incredibly undersized data set.  We achieved way more velocity in this sprint than Sprint 1, but because we committed to even more than that, not only is our PO pushing work to the next sprint, but we feel bad about it when we should feel good.

In other news, the new technology is a little easier to work with than we expected.  And the stories were more consistent technically, allowing us to minimize context switching and increase focus.  We talk about keeping this consistency bonus in mind when making up the sprint backlog but decide not to do anything official about it … yet.

How did our kaizen from Sprint 1 work out?  Having the backlog ready for Sprint Planning definitely made the sprint ‘feel cleaner’ but it’s not clear to anyone that this had any relationship to the bump from 18 to 50 points.

Our kaizen for the next sprint?  We took two 13 point stories into this sprint.  One of those definitely should have been split further, and 13 in general seems too risky for a team of this velocity, so our kaizen for next sprint is to not take in anything larger than an 8.

Note on sprint length.  We over-committed this sprint, same as Sprint 1, so post-retrospective we’re four weeks into this “Scrum” project and we haven’t built a proper sprint backlog.  With 1 week sprints we probably would have fixed this after week 2.

Further notes on sprint length, wherein I Praise A Tool For Expressing An Agile Principle

When I train Scrum and people ask me which tool they should use, I tell them I hate all tools equally but deign to use some of them.  Below is a Jira burndown chart from a sprint in progress (not this sprint as you can tell).  The red line is our progress, the gray line is the slope we need to meet to land this Sprint on-time.

wekendsNow this is a very small thing, but I absolutely love it to death.  Note how the gray line flattens out on that first weekend?  We configured Jira to use a standard 5 day work*** week and it’s smart enough to flatten the glide path on days when we’re not supposed to be working.

The Agile principle?  Sustainable pace. If people work the weekend on their own, that’s fine, you’ll take it.  But don’t setup any expectation that they do so, whether it’s the blatant act of over-committing, which we’re now struggling with, or the subtle pressure of a glide path that doesn’t include downtime.  Don’t be these guys!

*** If you configure your tool such that you have 7 day work weeks, turn in your Agile card now and go reflect upon your sins.

The Dog Food Diet: Sprint 1

releasehounds1

The team leaving Sprint Planning meeting.  From left, mounted, our Scrum Master and Product Owner.

Release the hounds!  We have a product vision and a team working to realize that vision.  Let’s see how they got out of the gate.

In an ideal world, the first sprint for a fresh team unrolls like the first 10 plays of a Joe Montana-led 49er’s team back in the 80s.  We roll down the field racking up first downs and eventually score a touchdown while barely acknowledging the other team’s existence.

In real life, IRL as the kids like to say, you almost never start fresh.  The team comes together from ‘doing other stuff’, some of the team is already working on the product, and if you’re just starting Scrum you’re getting people on board with the methodology.  These challenges have consequences and that’s where we are.

Sprint 1

Goal: Get the physical and mechanical elements in place to support the first installation.

There is a base lump of physical stuff that needs to exist to support a working prototype.  It needs to fit a physical form-factor and has some functional requirements like access and environmental control.  The physical and mechanical bits are a weakness in the team so there’s no question this is a right-sized, perhaps even aggressive goal for Sprint 1.

Velocity:  Total guess here, but we’re going with 40 points as our initial velocity based on a reference story that usually takes us less than half a day.  It’s a nice number, but of absolutely no use to us because ….

Sprint Backlog: Ummmmmm …. <see retrospective below>

Sprint Review: The goal of the sprint was, for the most part, met.  Physical requirements of the working prototype were in place and the base for an installation of the control and monitoring elements was established.  Dangling elements largely consisted of things that needed to be bought that hadn’t arrived in time.  In the PO’s estimation they didn’t materially detract from the goal.

Sprint Retrospective:  The PO says we met the sprint goal so everything’s great, right?  Not even close.  Check out the Jira burndown chart below.  If your burndowns look like this, you’re doing it wrong.  Let’s dissect the sprint reports and tease out the ScrumFail.

sprint1burndownchart

Just looking at the burndown chart, it looks like we took no work at sprint planning, sat on our hands for eight days, added a bunch of scope on day 9, added more scope on day 10, did some work on day 11, did some more work on day 12, then did nothing on days 13 and 14.  Who works like that?  Even so, we recorded a velocity of 18 points.

If we look at the second half of the Jira burndown report, we see what actually happened. Sprint planning consisted of taking the existing task list, imposing a rough ordering, and skipping the sizing.  We started with a boatload of issues, launched right into them but didn’t size them until one week into the sprint.  Jira reports this as a scope change of plus-40 on day 9 of our 14 day sprint.  We also burned down a number of issues before sizing them.

sprint1burndownlist

Note on Scrum burndown charts.  When you burn down hours, you’re burning down time on task.  There’s no hint of whether that time produced anything.  See here for the Mandatory Dilbert link.  When you burn down points, you’re burning down delivery of user-visible value.  The latter matters.  The former is about as useful in product development as a sundial

Week 1 was the enthusiasm stage.  Getting started was all-consuming. It wasn’t until week 2 that the SM and PO woke up and realized that they were foregoing a learning opportunity and, belatedly, fixed up both the backlogs.  Not good but not fatal either.

This is not unusual for a team starting with Scrum.  The team was working on some of this stuff already, had Scrum imposed on it on-the-fly and the SM/PO combination didn’t get its act together backlog-wise until the second week.  It happens.

Our kaizen for the next sprint?  Backlog appropriately groomed for next sprint planning.

Note on sprint length.  If we were working on 1 week sprints we would have ended Sprint 1 on Day 7 with zero work committed, zero delivered and a useless velocity metric.  On the plus side, we would have woken up on Day 8 staring at a total ScrumFail and fixed it earlier than we actually did with our 2 week sprint.  If we were a bigger organization, the second week of this ScrumFail would likely have been an ugly reconsideration of the entire Scrum thing.

 

The Dog-Food Diet: Yummy and Scrummy

IMAG0308

Klondike the wonder dog, strong proponent of the dog-food diet.

When you’re selling a product, the first thing people ask is do you use this product yourself?  Do you eat your own dog food.  Well, I sell Scrum and yes, I do eat my own dog food.  To be a little less snarky about it, I train Scrum and people always leave training with that trepidation about how to actually employ it in the field.  So, to show how it works, and the pitfalls that even an alleged expert runs into, I’m publishing this series of posts: The Dog Food Diet.

In these posts I’ll log and analyze the real-world management of a Scrum project, point out some of the things practitioners encounter and explain why they happen and what to do about them.   We’ll look at the progress of this project, the good, bad and ugly, from the Product Owner, Scrum Master and Team perspectives.

Unfortunately this is a stealth project so, against my usual practice of complete transparency bordering on TMI, I have to be oblique about what we’re actually doing.  In some ways this will be annoying and anodyne, in other ways it will  actually help us relate it to other projects that use different technologies and skill sets.

The system is a web-controlled, embedded device with sensors, based on new technology (i.e. not known-science).  The embedded device has some control elements (i.e. the embedded component actually DOES stuff other than sensing) in addition to simple information gathering.   There’s a web-based user-interface, cloud-hosting and a longer-term big-data element.  The overall project has mechanical/hardware elements, research elements, and a lot of software development.

Product Visioneuepofsaiuron

Any Scrum team starts with a product vision.  This product’s vision is classified but here’s the declassified version:

For people who want [to get the benefits of having a thing] our product offers the ability to create [that thing] over and over again as needed.

In contrast to [3 other specific ways of getting a thing] our product/service creates [a thing] at the same or lower cost while producing [a thing] that is higher-quality, meets [a certain regulatory requirement] and [certain non-functional requirements].

Personas

images

This is actually John Dillinger, not our product owner. Our PO does not wear a tie. Dillinger is a persona, but not one of our personas.

Who are we building this for?  We start with a single persona that roughly matches our Product Owner (left).  This is neither ideal, nor unusual.  It corresponds roughly to “building stuff for yourself” which is often an anti-pattern.  C’est la guerre.

To be less snarky about it, we’re building something for ourselves that we may be able to commercialize.   Think of it in manufacturing terms.  If your company build cars, for example, you may build specific tools in-house to fill the gaps between the commercial off-the-shelf tools that make up the bulk of your assembly line.  Some of those “jigs” may be interesting enough to consider commercializing.  That’s what we’re doing.

Internal ROI puts a fairly typical floor under the project.  It’s a success if it has a positive ROI even if only used in-house (i.e. never commercialized).  That ROI cuts both ways though – if the cost rises to the point where we’d have to commercialize it to stay in the black, then we need to reconsider the project.

Release Goal

The prioritized release goals for the first release are:

  1. A single installation, in-house that can remain in-use indefinitely with minimal intervention that’s lower-cost and higher-quality than the manual way we’re doing things now.
  2. Deep understanding of the new technology.
  3. Complete picture of the functional requirements of a productized version of the system, high confidence in the non-functional requirements of such a product and a roadmap and go to market strategy for a potential commercial version of the product.

In other words, we want a working prototype.

Team Launch/Working Agreements

How are we going to get this done?  These are our working agreements.

Sprint length

tapemeasureSprint length is a contentious topic.  I find myself disagreeing here with some of the most distinguished practitioners in the field so I will revisit sprint-length and its implications in every post.  We’re doing 2 week sprints.  Why?  Because I said so.  For the record, I’ve found 2 characteristics of 1 week sprints that make them less than ideal:

  • INVEST-able stories for 1 week sprints are much harder to write, and as a result you end up with many more stories on the backlog that don’t have user-visible value as the end result.  Writing lots of stories that don’t have user-visible value calls the value of Scrum itself into question.
  • The cadence of planning every Monday morning and reviewing every Friday afternoon tends to closely match the “beatings will continue until productivity improves” cadence of traditional waterfall projects.  Whether you do Monday-Friday or offset mid-week, with 1 week sprints your team members never get a break.  In 2 week sprints, the in-between weekend where there’s no sprint planning on Monday is a mental-health period.

Sprints start on Monday morning with Sprint planning, end two Friday’s hence with Sprint retrospective.

Ceremonies/Meetings

  • Sprint Planning – Monday at 10am every other week.
  • Standup – Every day at 10am, video via hangouts.
  • Review – Friday at 10am every other week.
  • Retrospective – Friday after lunch every other week.
  • Backlog refinement – as available at least once a week.

Artifacts

Jira for the backlogs, scrum board and burndowns.  No thought put into this – the team knows Jira and we already pay for it.

Definition of readyready

A story is ready if it meets INVEST criteria.  Dependencies that will typically need to be met within the sprint are mostly specification and procurement of parts.  We will not be doing wireframes (this may change).  Functional requirements come from the existing system, non-functional requirements to be supplied as acceptance tests.

Note on sprint length – we can spec-and-procure many more different types of parts in a 2 week sprint than a 1 week sprint.  With a 1 week sprint we’d be writing distinct specification and procurement stories paradoxically increasing our overhead in the pursuit of increased agility.

What we’ll find, on this project at least, is that we can spec, procure and write the code for many parts within a single sprint.  So in a 2 week sprint we have a story that reads like a story (“as a Josh-persona, I want to know that this sensor reading is out-of-range so that I can do something about it”) with sub-tasks that read like tasks (“spec the sensor”, “procure the sensor” and “write the code for the sensor”).  With 1 week sprints, the calendar time required to spec and procure (mostly procure) the part won’t allow us to take a story in that includes writing the code.

Definition of donedone

We have a variety of elements here and our definition of done is going to reflect that.

For physical elements:

It’s done if it works in-house and will continue to work indefinitely with little or no ongoing maintenance.  Specifically excluded are commercialization issues such as cost at volume, replicability, documentation, aesthetics or durability beyond an arbitrary lifetime of 1 year.

For mechanical:

It’s done if it works in-house and will continue to work for a year unmaintained, plus: design documents created or updated to reflect current state.  As with physical elements, aesthetics are not important.

For software:

It’s done if it works and will continue to work in test plus unit and integration tested. Deployed to production if possible, but we acknowledge that we will have to write some “deploy to production” stories as our access to production is limited by schedule to certain hours in the business day as well as by some ongoing, keep-the-lights on activity.  Correct functioning of the local user interface is not considered part of the DoD.

A peculiarity of our system is that there’s a local console on the embedded device through which a user can interact with the system as well as a remotely accessible web interface.  Our users will never see the local console so correct functioning of the local user interface, while helpful for development, is not considered part of the DoD.  This may be revisited.

**INVEST criteria for story readiness.

  • I – Immediately actionable
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

So we’ve set the terms for starting a Scrum team going forward to realize a particular product vision.  Next week we’ll see how the first sprint worked out.

Developers, Ecosystems, the Universe and Everything, i.e. 42

Someone once said that “at a startup you’re not competing with other startups, you’re competing with apathy”.  I’ve found this to be true over a long stretch in startup-land.  I never got crushed by competition, but against apathy my batting average is sub-Mendoza line.  I think about that a lot.  If you and I both jump in a lake, the fact that I floated longer than you did doesn’t matter much if we both drown.

greenhouseWhat brings this to mind is a discussion I had at a team dinner with the estimable Citizen Sigmund of Scrum Inc.  She mentioned some challenges she was having coaching Scrum with a particular team at a company out in a lightly populated section of the state.  The team-dynamics she described reminded me of a difference I always see between teams in hothouse ecosystems like Boston, New York, Seattle and San Francisco and those outside the hothouses.

In a nutshell,  even among comparable companies, it’s almost always more difficult to get teams to buy into tactical Scrum outside the hothouse.  And this is true even when these teams are failing and desperately unhappy.  They often seem like they’d rather fail in a way that’s familiar to them than succeed doing things differently.

sumoThe third leg of this observation, was a dark data point I gathered a lonnnnngggggg time ago.  Back in the day I figure skated.  Yes, it was often as funny as it sounds.  And having done it for many years, I had a certain impression of how I looked out there, how good I was.  Then I saw myself on video.

Oh, ignorance was certainly bliss.  When I skated, it felt good, so it must look good … it must be good.  It wasn’t.  Same thing happens to dev teams in the wild.  They get into a way of working and the paychecks keep coming so it must be good.  But it often isn’t and they have NO idea because they’re not surrounded by world-class competition.

How does this relate to startups and apathy?  It’s the age-old question of how do you know when you’re succeeding.  Startups often measure themselves against each other – how much money we’ve raised for example – when what they need to measure their success against is their market’s innate inclination to DO NOTHING.

When I skated, I knew what good skating looked like from seeing good skaters in person, and on TV, but I didn’t know what I looked like.  Devs in the wild have the opposite problem.  They know what they look like, but they don’t know what good devs look like.  They only have each other to refer to, not a wider pool of people doing the same thing in different ways.

What does it all mean?  Measure things, don’t assume you’re doing well as I did on the ice before the age of video.  Measure the right things, don’t be That Guy sitting around at Starbucks bragging about how much money your company raised.  And finally, compare your, your team’s, and your company’s metrics to the best in the world, not just to the people and companies in your immediate vicinity.

 

 

Some Concrete Things To Think About With Technical Co-Founders

I talk to a fair number of people who are looking for technical co-founders to help them build web-based businesses.  When we get to the point where we decide not to work together, the smart ones always ask me if I have any advice for them moving forward.  And I do.  Here it is.

cofounder.jpg

It’s tempting to think of yourself as the next Steve Jobs and to imagine that the bearded man you’re having coffee with later today is the next Steve Wozniak.  Not happening.  You’re not Steve Jobs and that guy you met on cofounderslab is just an ungroomed jumble of untested technical skills, social awkwardness and unknowable cofounder potential.  The question is – What can he do for you in the next 18 months?

If I were a non-technical cofounder building a web app from scratch I’d have two demands of a technical cofounder, or contract house. First, that they build good stuff – i.e. that the product work and that it looks good.  Duh. Second, that they can create, and from day one deploy to, a continuous integration infrastructure – aka immutable infrastructure.

“CI from day one” means throwing away a little bit of time in the beginning setting it up, and dedicating a little bit of cash burn in the long run. For your purposes, CI is a system that can take a change to a web site as committed to source control, run automated tests against it, raise a flag if the tests fail, or deploy successfully to staging/production if they pass.

cheeseburger.jpg

Think of your infrastructure as a sort of 3D printer that takes your designs and turns them into real-world objects.  Your business, at heart, is a machine for producing iterations of a web site.  If it can do that quickly, at high quality, it may be worth something someday.

If your business produces iterations of a web site that take days to code trivial changes and those changes fail deployment every single time you go to production then what you’ve built is not a business – it’s a learning experience.

What you will get if you talk to the young and ambitious crowd is a lot of people who:

  • can work within an infrastructure that someone else has set up OR
  • can set up a one-off web site from scratch in the cloud using a bare-naked Linux instance with a bunch of stuff configured on it and can redeploy manually, or via source control (not deployment packaging).

They have no idea how to setup something that multiple people can contribute to, that automates testing, and that deploys correctly every single time.

bus-factor.jpg

If you set up immutable infrastructure, the bus-factor for your technical co-founder goes to zero, which is something that you desperately want and that they shouldn’t fear.  But even better, when you have an infrastructure that works, you can profitably employ all those cheap and available people who can only do good work within a working infrastructure – e.g. junior web devs, recent Startup Institute grads …

And if you’re thinking about outsourcing – you must, must, must own your own infrastructure, every little bit of it including DNS.  And think very carefully about the access rights and take continuous backups.  Get a friend to setup the accounts if you have to, but don’t rely on your outsourcer to do it, and don’t have them as administrative owners of any piece of it.  Having your outsourcer provision your infrastructure works great right up until the first time the two of you disagree about money.  Ask me how I know this …

I would also spend some time reading up on the concept of a Scrum Product Owner, even if you don’t intend to ‘do scrum’. As founder you have the ultimate authority over everything, but some of these responsibilities you’ll entrust to people you collaborate with. After all, you don’t want to micro-manage.  That’s fine, but the PO concept defines the set of things that, as “product person”, you need to own and not compromise about.  I’ve found over the years that successful companies, even ones that don’t do Scrum, concentrate the same set of responsibilities within product management that Scrum entrusts to Product Owner.

And, from day one, implement the concept of the sprint demo. You will find, talking with devs, that you’ll ask the question “Is it done?” and they’ll say “Yup, X, Y and Z are all set.” Only later will you discover that “it” and “X, Y and Z” are different things. If it’s done, prove it, and if you can’t show it, it ain’t done. This is HUGELY important with outsourcers.  The sprint demo is about quality and accountability.  Live it.

Notice that I haven’t said anything about stack.  Frankly I mostly don’t care about the stack and you shouldn’t either. RoR with some javascript framework seems to be a standard thing, and well-known among the offshores, but there’s a dozen good ways to write a web app these days.  In any case, whatever stack I recommended today would be wrong tomorrow.  Immutable infrastructure, on the other hand, is a sine qua non from this point forward.

In a nutshell, here’s my advice:

  • Immutable infrastructure
  • Own your own infrastructure
  • Be a Product Owner
  • Enforce the Sprint Demo

And remember, easy for YOU to do is easy for ME to say.  Ahh, the joy of blogging.

Why US Healthcare Sucks – part 1 of 243

I am preaching to the choir today so if you think any of the following list of things, fuck off and go read someone else’s blog.

  • The US has the greatest healthcare system on earth
  • If you don’t like it here, move to Canada

Early one Thursday morning, my family and I were visited by a bat.  We were all asleep in relatively close proximity, and thus were all exposed to the cute little critter for a good little while before someone had the consciousness, and good sense, to scream about it.  Good times.

dragonNow, I’ve had experience dispatching bats, and this one was no more difficult than the last.  In fact, I used an aquarium net to knock him down (and out), scoop him up and toss him out on the lawn for the neighborhood cats to deal with.   At left is an artist’s rendition of the foul beast in flight shortly before I smote him.

 

I immediately got on the trusty iPad to figure out what to do about the damned bats, this being #3 in the last couple of years.  In the course of my investigation, I was shocked (shocked I tells ya) to discover that, by Department of Public Health standards, I either needed to find and autopsy the bat, or we all needed to get rabies shots.  Because we were in the room.  With the bat.  While we were sleeping.  Here’s a link.  I didn’t believe it either.  But that isn’t the sucky part of our healthcare system, not by a long shot.

Annoyed but not alarmed, I searched the lawn in vain for my vanquished foe.  Alas, he was nowhere to be found.  I like to think that Nigel, the cat next door, got him because I don’t like Nigel either and that would be a two-fer. The family all slept for another hour, went out to see the Perseid meteor shower, then slept again.  The bat was unavailable for testing, and we would deal with it in the morning.

At this point, I have a family of four and we all needed rabies shots (according to DPH criteria) because we were all exposed.  And they needed to start before 1am Friday.  24 hours from exposure.

Here’s where the US healthcare system starts to shine its peculiar menacing glow.  My wife works for a hospital that self-insures.  That should have made this easy.  Instead, a voyage of discovery within her employers and her PCP’s labrynthine systems produced the advice that the entire family should go to the emergency room.  Not only that, but we should call ahead to make an appointment.  The irony of making an appointment at the Emergency Room did not make anyone laugh.  The irony of paying 4X an emergency room charge ($100 each) rather than the 20$ copay for an urgent care visit did not make me laugh either.  This was clearly not yet an emergency as any normal person would define the word.

But as any procrastinator knows, you can turn anything into an emergency if you wait long enough, and by early afternoon my wife (who has a job above and beyond finding out where to get rabies shots) was stuck with the emergency room as our only option.  We had about 12 hours to start the series, and about 4 hours before the healthcare system in general stopped answering the phone.  This was clearly not an emergency, but if it could stiff-arm us for another 4 hours the healthcare system would turn it into one.  My resolve not to contribute to the rampant abuse of emergency room care was wobbling.

receptionistSo off to MY PCP I went.  My PCP works in a big, nice, multiple-group practice.  I like the building, which has nice bathrooms, and many of the people within who sometimes help me feel better when I get sick.  That said, interacting with my PCP’s office is an act of desperation because they have always been dreadful to deal with.  They did not disappoint.  The moron who screens calls there seemed unable to comprehend that, at 3pm I didn’t have the luxury of setting up an appointment only for myself, and only to “talk about it”, when the entire family was exposed at 1am that day.  You have 24 hours to start the rabies series.  If I had to make “talk about it” appointments at 3 different PCPs we’d end up in the emergency room anyway.  I had other people relying on me to take care of them and this moron was simply unable to comprehend this, or more likely did not have the authority to do anything but repeat over and over again “do you want an appointment for yourself or not?”.  She does however have the authority to tell me she doesn’t like my attitude. She puts me, so she claims, in the queue for a callback.

Now I know that answering calls at a doctor’s office is not a fun job.  I know that talking to me is not always a fun job. I know that the men who profit wildly from the existing system (administrators, payers, doctors) hide behind the women who don’t (nurses, receptionists, assistants).  I know that the people I talk to on the phone do and say only what their tightly proscribed role allows because they need a job and, in an at-will state like Massachusetts, can be fired for no reason at all.  I know all that.

Still, the overwhelming impression one gets from working with my PCP’s office is that they really don’t like people who … need a doctor.  That the organization itself exists for some other reason than, for example, to give rabies shots to people who need them.  I struggle to imagine what that reason might be, yet there it is.

I received my callback from the PCP 5 days later at which point, had I waited for it, I would already have rabies.  I suspect that might have been okay with my PCP’s receptionist – after all, people with bad attitudes deserve to get rabies.  In any case, that fool, and that foolish system would have put four people in the emergency room when their PCP, Harvard Vanguard Braintree was perfectly well equipped to handle the issue in a timely fashion.

That’s why the US Healthcare System sucks.