The Dog Food Diet: A Product Ownership Interlude


As Dilbert once said (sort of) “Welcome to product management.  Two drink minimum.”  At this point, 6 sprints into the project our release burndown looks something like this:

Screen Shot 2017-12-20 at 6.53.15 PM

Aaaaaaannnnnnyyyyyyyhooo …. 

This release is going to happen, probably sometime around Sprint 10.  There is no question that the product works and the functional release goals will be substantially met.  There are stories that have appeared out of nowhere and gone to the top of the backlog, stories that seemed critical that have fallen to the bottom of the backlog and stories that have failed in execution and had to be reworked from scratch.

Given that this is an internal release there’s little angst that goes into “calling it done”.  The more interesting questions revolve around what comes next.  After this release we’ll have something with a positive ROI when sold to one customer, us.  What about customers who aren’t “us”?

Up to this point we’ve put a small handful of PO stories on the backlog.  Generating lean canvas for the product, maintaining an up-to-date bill of materials to give us an upper-limit unit cost, and some better-than-internal documentation.  Now our PO needs to build a decision about whether or not to sell the product to people who aren’t “us”.

We’ve reached a commercialize-or-not decision for the product.  The team, including the PO, desperately wants to commercialize.  You want them to want this.  “Purpose” is a key part of motivation (Autonomy, Mastery, Purpose) and if your team doesn’t feel they are serving a big, worthwhile purpose then they won’t perform well.  But this means that if the team and PO just sit down and talk about whether or not to commercialize all you’ll hear is various flavors of “Hell yeah!”.  We need metrics.

Because of the company’s unique (alright not-so-unique) position, “time to break-even” and “maximum exposure before break-even” put hard limits on the investment we can make in the product.  A version of the product that takes too long to break even, or takes too much investment to launch at all would require the company to bring in a round of investment, which pushes the decision up a level from the PO/Management Team level where it lives now.  Again, typical constraints.

Getting those metrics done well, and being hard-headed about them is top priority.  What do we need to get those metrics?  For this particular product:

  • Cost of labor to build this.  This should fall out from a well-constructed product backlog and the velocity metrics we’ve already produced.
  • Legal and regulatory.  There are expensive regulations that need to be met to commercialize this, we know what they are, we just need hard numbers and timelines about how to meet them.
  • Cost of go-to-market.  Given a product that meets regulatory and does things people will pay for, what does it cost us to get them to buy enough of it that we reach break-even without breaking our total investment ceiling?

Second priority is the potential return on this investment.  We split this into two questions that will look familiar to fans of Lean Customer Development:

  • Does anyone besides us have the problem this product solves?
  • How many people have this problem and what will they pay to solve it?

Scrum Implications of Commercialization Decision

2drink.pngWhat does all this mean for the team?  In large companies, except for the BOM and people-cost, all this “business stuff” would disappear into a black hole of decision-making populated by business trolls doing exclusively business stuff.  But we’re a small company and we need to do all this with pretty much the same team that’s actually building the product.

We’ll use a typical structure that enables swarming.  Our PO will structure the Lean Customer Development stories, and the team/PO will figure out how to get them done and run them off the same Sprint Backlog that we build the product from.

On top of all that, the team realizes that given the amount of work and sheer calendar time that needs to go into this decision, we’re very late getting started.  Customer development interviews, in particular, eat calendar time.  We’ve already started Sprint 6, with almost exclusively product development stories and won’t want to wait two weeks to start on commercialization stories.  Fortunately, our kaizen from Sprint 5 was to implement the interrupt buffer pattern and we now have 10 points of interrupt we can draw from without angst.

So What Do We Do First?

There’s a bunch of stuff we need to do to build this commercialization decision.  That stuff becomes stories on our product backlog.  Our team is doing backlog refinement weekly, so our PO needs to write those stories, get them sized and prioritized, recognizing that he has only 10 points of interrupt for this sprint where he can jam in unplanned work.

Notes on sprint length (are you bored with sprint length yet?). This once again argues for one week sprints over two weeks.   Realizing that it will take at least a couple of days to create new PO stories, we could easily put off starting on them until next week in a one week sprint system.  In a two-week sprint system we’re forced to use interrupt buffer to accommodate the urgency of these PO stories.






The Dog Food Diet: Sprint 6

messywiresSprint Goal: Cleanup installed hardware and implement one internal-feedback controlled function.

We’ve explicitly excluded physical aesthetics from this first release but there are limits to everything and the mess of wires in production threaten to make trouble down the road.  Add to that the fact that we need to take production apart to enable some of the control-function stories (wires that weren’t brought out to an accessible terminal) and it makes sense for this to be a goal.   Feedback controlled function is the embedded system making an intelligent, sensor-based, not schedule-based, local decision to “do something”.

Sprint Planning:  Our velocity is 54 and we take 54, including an interrupt buffer which we eyeball at 10 points.

Everyone’s anxious that the product backlog is thinning out and starting to be dominated by business value research stories, bigger, more difficult technical stories and stories that apply more strongly to a commercial version of the product than to an in-house version.  A decision point is looming for our PO structure.

Sprint Review: We showed the radically reorganized installed hardware and a control function directed by internal sensor feedback.   The sprint goal was met, and with room to spare.

Screen Shot 2017-12-20 at 6.41.10 PM

Retrospective:  Lots to talk about at this retro.  Looking at the chart, we flat-lined for the first three days, got on the curve then flat-lined again.  We’re repeating a pattern of floating “above the curve” for most of the sprint and bringing it in, if we do, at the end of the second week.  This could mean we’re taking in stories that are too big but looking at the second half of the burndown chart report we see that the stories we burned were all ones, twos and threes so we’re good there.

This floating above the curve phenomenon is a builtin tension to doing almost anything, by almost any methodology.  Jeff Sutherland always compares burning down work to landing an airplane which is a great visual analogy.   The biggest problem with floating above the curve as a way of life is that it has a completely ill effect on both the Scrum Master and Product Owner.  Your SM and PO can have confidence that you’ll land the plane, but it will be based on faith, and history, not on the current state of the chart.  There may be a happiness metric benefit to, every now and then, taking a quick win at the start of the sprint.

Despite our velocity, we also had three dangling stories that fell into two camps.  One was a story that was complete except for deployment to production.  Remember, like any ongoing business we’re limited in our access to production and the size of the window we can bring it down.

The other was a pair of stories having to do with controlling a motor.  The team fears it.  It’s messy and risky so no one wants to touch it.  It was probably a mistake to put them at the end of the sprint backlog where they’d be easier to punt.  We’ll swarm at least one of them at the beginning of Sprint 7.

Jira note: We took in two stories about the same physical part – a three pointer to jury-rig it to get another week out of it, and a five pointer to replace it entirely.  We ended up doing the five pointer on day eight without needing to do the jury-rig so we removed the three pointer from the sprint.  In the burndown chart that descoping is represented just like completed work, but Jira is smart enough not to count it toward our velocity.

How did our kaizen from Sprint 5 work out, part 1?  TDD – TDD was epic.  The team loves it so much we started looking at BDD.  Note that like most everything that seems radical and new, BDD is actually a decade old now.

When we took this kaizen, we estimated it at 5 points.  Then I realized that it was stupid to size this kaizen.  That’s what you see on day 5 where five points disappear from the scope of the sprint.  My thinking here went as follows.  TDD requires effort, but that effort for each story is part of the story itself, not a separately sized thing.  And theoretically it should be speeding us up, so if we count velocity for doing TDD and get a velocity bump on the individual stories, we’ll be double-counting one kaizen which we’ll have to “give back” next sprint when it’s not the kaizen anymore.

So put the kaizen on the backlog, but don’t size it because it doesn’t directly create business value.

How did our kaizen from Sprint 5 work out, part 2?  The interrupt buffer came in handy almost immediately.  On the fifth day of the sprint we had a production emergency, three point story.  So we added a three point story to the sprint backlog.  But we want those three points to “come out of the interrupt buffer”.  So we reduced the point estimate on the interrupt buffer to seven.  That’s the spike that shows up on day 5.  Adding three points of scope for the new stories, subtracting three points of scope from the interrupt buffer.  And when we burned down those three points on the same day, we end up, as we expect, on the same slope as if we’d just burned a three-pointer from the sprint backlog.


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.


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.


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).





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


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.


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.


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


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].



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.


  • 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.


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.


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.


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.


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.