As we prepare to bring our new Discovery ops person on board in a couple weeks, we have been talking about how to integrate Guillaume's workflow into our process. The following strawdog proposals are based on conversations that involved me, Dan, Guillaume, and others.
1. Meetings
We propose having Guillaume attend the search team standups for now, since 90+% of his initial work will relate to search. He would probably not any of the sprint planning or backlog grooming meetings. It's not clear whether we should have a weekly Ops planning meeting, which would resemble the Analysis planning meetings we already have.
2. Phabricator
We would create a Discovery-ops-sprint project/board, which will represent the work of the Discovery ops team. This aligns with how we have handled the Maps and WDQS sub-teams, which are also very small teams.
3. Learn and iterate
Whatever we end up trying as a starting point, we'll inspect and adapt it as we go.
Any questions, comments, concerns, or questions?
Kevin Smith Agile Coach, Wikimedia Foundation
Thanks Kevin! All sounds good to me.
Dan
On 15 January 2016 at 15:15, Kevin Smith ksmith@wikimedia.org wrote:
As we prepare to bring our new Discovery ops person on board in a couple weeks, we have been talking about how to integrate Guillaume's workflow into our process. The following strawdog proposals are based on conversations that involved me, Dan, Guillaume, and others.
- Meetings
We propose having Guillaume attend the search team standups for now, since 90+% of his initial work will relate to search. He would probably not any of the sprint planning or backlog grooming meetings. It's not clear whether we should have a weekly Ops planning meeting, which would resemble the Analysis planning meetings we already have.
- Phabricator
We would create a Discovery-ops-sprint project/board, which will represent the work of the Discovery ops team. This aligns with how we have handled the Maps and WDQS sub-teams, which are also very small teams.
- Learn and iterate
Whatever we end up trying as a starting point, we'll inspect and adapt it as we go.
Any questions, comments, concerns, or questions?
Kevin Smith Agile Coach, Wikimedia Foundation
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Hello all!
It was great meeting you! And I'm sure it's going to be just as much fun working with you!
Comments inline...
On 15 January 2016 at 15:15, Kevin Smith ksmith@wikimedia.org wrote:
As we prepare to bring our new Discovery ops person on board in a couple weeks, we have been talking about how to integrate Guillaume's workflow into our process. The following strawdog proposals are based on conversations that involved me, Dan, Guillaume, and others.
- Meetings
We propose having Guillaume attend the search team standups for now, since 90+% of his initial work will relate to search. He would probably not any of the sprint planning or backlog grooming meetings. It's not clear whether we should have a weekly Ops planning meeting, which would resemble the Analysis planning meetings we already have.
Sounds like a good starting point to me.
- Phabricator
We would create a Discovery-ops-sprint project/board, which will represent the work of the Discovery ops team. This aligns with how we have handled the Maps and WDQS sub-teams, which are also very small teams.
If 90% of my work is going to be search related at first, I'd actually prefer to keep that in the Discovery-Search-Sprint [1]. I think this would provide better visibility on what the search team is doing as a whole, and if it all make sense, my tasks should more or less strongly related to the other tasks of the search team. It would at least push me a bit more to see what the rest of the team is doing.
In any case, we'll see as it goes and iterate to make it better.
- Learn and iterate
Whatever we end up trying as a starting point, we'll inspect and adapt it as we go.
Side note:
Some explanation of my bias: My experience is that a shared Kanban is a very nice tool to transform push people to work as a team and not as a collection of individuals. I have used Kanban for quite sometime to push team objectives forward and not individual performance (if this specific task is not my strong area, but it is what needs doing now, I'll do it because it's the next task in the backlog). The approach optimizes lead time / flow at the cost of cycle time / throughput.
As always, feel free to ignore my rants... ;-) In any case, it will take me some time to contribute much, so it probably does not matter all that much at the moment.
Any questions, comments, concerns, or questions?
Kevin Smith Agile Coach, Wikimedia Foundation
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
[1] https://phabricator.wikimedia.org/tag/discovery-search-sprint/
On Fri, Jan 15, 2016 at 5:44 PM, Guillaume Lederrey < guillaume.lederrey@gmail.com> wrote:
- Phabricator
We would create a Discovery-ops-sprint project/board, which will
represent
the work of the Discovery ops team. This aligns with how we have handled
the
Maps and WDQS sub-teams, which are also very small teams.
If 90% of my work is going to be search related at first, I'd actually prefer to keep that in the Discovery-Search-Sprint [1]. I think this would provide better visibility on what the search team is doing as a whole, and if it all make sense, my tasks should more or less strongly related to the other tasks of the search team. It would at least push me a bit more to see what the rest of the team is doing.
In any case, we'll see as it goes and iterate to make it better.
I think you have convinced me. Not only will most of your work initially be with the search team, but you will be taking over duties that search team members have been responsible for. So by leaving that work on the search board, people like Erik and David would be able to see it, comment on it, review it, and even take it on if/when that would make sense.
Some explanation of my bias: My experience is that a shared Kanban is
a very nice tool to transform push people to work as a team and not as a collection of individuals. I have used Kanban for quite sometime to push team objectives forward and not individual performance (if this specific task is not my strong area, but it is what needs doing now, I'll do it because it's the next task in the backlog). The approach optimizes lead time / flow at the cost of cycle time / throughput.
Pure Kanban would definitely expect each person to pull the next task, whether or not they were best suited to do so. Our teams (like many) have people with a variety of skills, so it's usually more efficient to have people take the next task in their domain. Essentially, we have been operating closer to Scrum than Kanban that way.
At some point, we might have to choose to go more strongly toward Kanban, or toward Scrum. Our current middle ground was easy to get started, but probably isn't optimal.
Thanks for sharing your ideas!
Kevin Smith Agile Coach, Wikimedia Foundation
Just please make sure to loop Erik in as he's drafting the on-boarding doc.
thanks
--tomasz
On Mon, Jan 25, 2016 at 3:05 PM, Kevin Smith ksmith@wikimedia.org wrote:
On Fri, Jan 15, 2016 at 5:44 PM, Guillaume Lederrey guillaume.lederrey@gmail.com wrote:
- Phabricator
We would create a Discovery-ops-sprint project/board, which will represent the work of the Discovery ops team. This aligns with how we have handled the Maps and WDQS sub-teams, which are also very small teams.
If 90% of my work is going to be search related at first, I'd actually prefer to keep that in the Discovery-Search-Sprint [1]. I think this would provide better visibility on what the search team is doing as a whole, and if it all make sense, my tasks should more or less strongly related to the other tasks of the search team. It would at least push me a bit more to see what the rest of the team is doing.
In any case, we'll see as it goes and iterate to make it better.
I think you have convinced me. Not only will most of your work initially be with the search team, but you will be taking over duties that search team members have been responsible for. So by leaving that work on the search board, people like Erik and David would be able to see it, comment on it, review it, and even take it on if/when that would make sense.
Some explanation of my bias: My experience is that a shared Kanban is a very nice tool to transform push people to work as a team and not as a collection of individuals. I have used Kanban for quite sometime to push team objectives forward and not individual performance (if this specific task is not my strong area, but it is what needs doing now, I'll do it because it's the next task in the backlog). The approach optimizes lead time / flow at the cost of cycle time / throughput.
Pure Kanban would definitely expect each person to pull the next task, whether or not they were best suited to do so. Our teams (like many) have people with a variety of skills, so it's usually more efficient to have people take the next task in their domain. Essentially, we have been operating closer to Scrum than Kanban that way.
At some point, we might have to choose to go more strongly toward Kanban, or toward Scrum. Our current middle ground was easy to get started, but probably isn't optimal.
Thanks for sharing your ideas!
Kevin Smith Agile Coach, Wikimedia Foundation
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery