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 <[email protected]> wrote: > On Fri, Jan 15, 2016 at 5:44 PM, Guillaume Lederrey > <[email protected]> wrote: >> >> > 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. >> >> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/discovery > _______________________________________________ discovery mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/discovery
