On Wed, Apr 13, 2016 at 6:16 PM, Kevin Smith <ksmith(a)wikimedia.org> wrote:
This is a ping to remind you about action items we
ended up with from our
March retrospective, in case you haven't acted on them. Sorry this is so
late!
Mikhail: Check whether meta Discovery/Testing page is up-to-date
Guillaume talk to robh to understand how procurement works
-> Done. I have probably not understood everything yet, but I'm
getting there (slowly). One of the things I've understood that might
interest some of you (you probably know it, but we never know): There
are 2 workboards worth watching if you want to know the status of
hardware requests:
Hardware-request board [1]:
Tracks all hardware requests. If you are waiting for hardware, but the
task does not show up in that board, your task is probably lost and
Robh is not working on it (and I'm probably not going to find it
either). Columns are self explanatory and give you some visibility on
the status.
Procurement board [2]:
Once the hardware request is approved, a procurement task is created
and will move forward in the procurement board. As those tasks
contains price information that we are not allowed to share, the
access is restricted.
The full procurement process is documented on Office wiki (again, some
private info there, so not public).
Should probably have an automatic task to announce
each test
Think more about velocity question: Hire more? Change process? Is it OK as
is? Start doing guesstimations?
Before changing the way we do things (hire, process improvement,
estimation, ...) I think we should put in place a few metrics, so that
we know if our changes improve the situation or not. I had a quick
look into the reports available out of the box from Phabricator, and
they seem a bit lightweight (to say the least). I might just not be
looking at the right place (I have been known to do that).
The first metric I'd like to see is something about cycle time (how
long do we take to finish a task once we started working on it). Or a
Cumulative Flow Diagram, which should give us visibility on our cycle
time and might give more insight on its evolution over time.
As you see, I'm a big fan of metrics. Now that I've made my point, I'm
not actually sure it make sense to invest in better visibility in our
team. So far I have not felt like we have an issue in delivering
value. Digging into how we work, creating metrics, following them does
not come for free. So the usual "if it's not broken, don't fix it"
probably applies here. You know that better than I do...
Announce the past test(s)
I think Dan already did that third item. The fourth was probably on my
plate, but I haven't had a chance to do it, so I'll probably leave it as an
action item coming out of the April retro.
Who would be best to handle that last item, or has someone already done it?
Kevin Smith
Agile Coach, Wikimedia Foundation
[1]
https://phabricator.wikimedia.org/project/view/1014/
[2]
https://phabricator.wikimedia.org/project/view/1155/
[3]
https://office.wikimedia.org/wiki/Operations/Procurement
--
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation