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.

Scrum Point Accounting for Unfinished Stories

Here’s one for the Scrum nerds out there.  Working with Joe Justice of Wikispeed, I cooked this post up because this is the last time I want to have to refigure this out from scratch.

beancounterThere’s a point that comes up every time I train or coach Scrum teams related to whether or not you re-estimate a story that was unfinished at the end of last sprint when you take it into the next sprint.  It drives me crazy because I personally despise hour-based project management accounting and these sorts of questions evoke bad memories of waterfall projects and PMP project managers.  I’m also really bad at math.

So let’s take a look at what happens when a story is half-finished and carried over to the next sprint by teams using different accounting methods.

conservationofpoints

The chart above shows the burndown for a hypothetical 40 point release (eight  5 point stories) by three different 10 point teams.  All three teams completed the release.  Team 1, in blue, burned down the project smoothly 10 points per sprint.  Don’t laugh, it could happen!  No accounting issue there.

Team 2 didn’t complete one of the 5 point stories in sprint 1 and got 0 points for it in that sprint.  They took it into Sprint 2 as a 5 point story, completed it along with two more 5 point stories.  They recorded 15 points of velocity for Sprint 2 and got back on the ideal burndown for the rest of the release, burning those 40 points down to 0.

Team 3 also didn’t complete one of the 5 point stories in sprint 1.  They also took that story into Sprint 2, but re-estimated it at 2 points.  They completed that incomplete story, now valued at 2 points along with two 5 point stories the same as Team 2.  But because they re-estimated the remaining work on the unfinished 5 pointer as 2 points, they recorded only 12 points of velocity where Team 2 recorded 15 for the exact same amount of work.  Essentially, the release lost 3 points of work.

Shrinkage

The method team 3 used, and the one I’ve advocated up until recently, I call Shrinkage.  That’s because the amount of points recorded to complete the release goes from 40 to 37 when the unfinished 5 point story gets re-estimated.  3 points simply disappear from the release.  I like it for some very tactical, team psychology, Scrum Master oriented reasons:

  • It forces us to be honest about the work
  • It helps teams avoid the trap of simply taking the product backlog estimate of a story into the sprint backlog
  • It reinforces the notion that incomplete work is waste
  • It exercises the team’s relative sizing muscle

Conservation of Points

The method of team 2, where they didn’t re-estimate the remaining work but simply took the story into the next sprint at the original estimate I call Conservation of Points.  The three points of work on the unfinished story in Sprint 1 are carried over into Sprint 2 and accounted as Sprint 2 velocity even though the work was done in Sprint 1.  No points disappear from the release.

Recommendation

I recommend using Conservation of Points now for one, and only one reason.  In a Shrinkage model, in order for the release burndown to continue to fulfill its purpose, the product owner needs to account for the lost points.  The PO needs to shift the whole curve down, so that instead of starting at 40 points for the release, it starts instead at 37.  Some automated tools may support this, but in a manual situation or where you’re tracking in Excel this can be a real pain in the neck and stuff that’s a pain in the neck ends up not getting done.

UPDATE: As commenter Nigel Thurlow points out, if you use Conservation of Points you must use a rolling average for velocity in Sprint Planning.  Using the single data point of “last sprint’s velocity” as your sprint planning velocity (rather than a rolling average) will leave you chasing bad data up and down the burndown chart, essentially amplifying the negative effects of unfinished stories.

Acknowledgements

Many thanks to Joe Justice of Wikispeed and my friends at GE Power and Water in Mumbai who inspired me to finally write this down.