launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

Hello Launchpadders,

The Teal squad together with the Product team are running a bit of an
experiment in the way we develop features.[1] The main idea is that
every two weeks, the squad aims to deliver *something* that gives user
benefit and the Product team does a thorough test of that.

What follows is much more detail. Stop here if you don't already care.

Please be forgiving if I've been unclear or confusing. I'll be happy to clarify.

We have delivered a few features since we started the whole LEP thing.
During that time, I've learned and noticed a few things:
 * LEPs are pretty useful, and people don't seem to mind them too much
 * User testing is really useful
 * Exploratory testing seems to be just as useful (early days though)
 * polishing UI takes time, not simply person-hours, but actual time
 * we often tend to do UI last after the backend is done
 * it's difficult for me to be responsive toward the end of feature
development, and often things drag out
 * feedback at the end of development is often demoralizing for the
squad (what! more work?) and for me (what! we're going to release with
this bug unfixed?)
 * if you are outside a squad, it's quite hard to get a picture of
what state the feature is in. This makes both testing and stakeholder
communication difficult.
 * there has been lots of accidental scope change
 * the interface between feature squads and the product team has felt a bit hazy

I guess there's more, but that's what I've got now.

Part of this has been because we have mostly taken on really, really
big features. We are going to try to do less of that in the future,
but sometimes it's unavoidable.

Otherwise, I think we can make some of the problems go away if we
regularly release changes that deliver benefit to their intended
users, and if we test those changes. This isn't a revolutionary
notion.

We picked two weeks because it seems a time in which something
meaningful can be done. It sucks a bit that every second cycle won't
be able to have DB patches, but we can deal with that, and we're going
to fix that soon anyway.

We're stressing "benefit to users" partly because that's, you know,
what we're here for, and partly because that near guarantees that it's
testable. Also, it means that we get time to polish things as we go,
rather than in one big long polish session toward the end of
development. I care a lot about us releasing polished features.

I definitely do *not* want us in a situation where we say "Thing X
must be done by Date Y, or else". I just want something, *anything*,
that helps the users once every two weeks. Over-deliver,
under-deliver, exactly deliver – doesn't matter, just get something
out. We'll test it, and there'll be other cycles to get it better.

This is long and rambling. Sorry. I'm happy to answer questions.

jml

[1] https://dev.launchpad.net/PolicyAndProcess/FeatureDevelopment