On Wed, Apr 13, 2016 at 6:16 PM, Kevin Smith ksmith@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