Re: [teampractices] A tool for keeping action items accountable?
In another life, I have been facilitating a few retrospectives. Not here yet, so the context is probably different and this past experience probably does not apply without the necessary amount of tweaking. Still: The usual rule we put in place with our teams was: "A retrospective action must have a fairly limited scope and be possible to implement before the next retrospective". Larger items are not considered to be retrospective actions, but might be put into the team backlog. Action items are the responsibility of their owner (if we can't find an owner for the action, the action is dropped). The facilitator responsibility is to check the status of those actions at the next retro. If those actions have not been completed by the next retro, they are either dropped (if we did not make progress, they are probably not as important as we thought), converted as backlog item (they were larger than we initially thought), or kept as action item for the next retro (rare case). With those rules, we don't rely on specific tools... No idea how this applies at WMF... On Wed, Apr 27, 2016 at 9:55 AM, Quim Gil wrote: > Could you provide examples of these "action items"? It will help > understanding the relevance of "non-dev/product" action items coming out of > (presumably dev/product) sprint retrospectives. > > This sounds like a matter of threshold: > > * If an action item is purely personal, then sure, use the purely personal > tool to deal with it. > * If an action item has an impact on the team, then use the team tool to > deal with it, no matter how simple, small, "non-dev/product". > > Is it fair to assume that most actions coming out of a sprint retrospective > will have impact on the team? > > This is where the fear to i.e. bringing back Trello doesn't sound any > visceral to me, but well justified. Someone starts creating strictly > personal actions in Trello (Asana, etc), they continue adding other small > actions because 'since we are using this tool anyway and I'm writing the > actions quickly after the meeting'... Three months down the road that > parallel board has got a life on its own, they start having tasks > duplicating with the team's tasks in Phabricator, some things fall between > the cracks... > > Yes, I know this would not happen to *you* or *your* team (whoever *you* > are), but looking at our history we have solid reasons to think that this > will certainly happen to *someone*, and then that will be taken as a > reference by * someone else* not reading this thread today, and then... > > > > On Wed, Apr 27, 2016 at 1:49 AM, Max Binder wrote: >> >> The first thought was to use existing Phabricator boards, but the team >> agreed that Phab was a lot of overhead for reminding folks to follow up on >> non-dev/product tasks. > > Why overhead? Creating a minimally acceptable Phabricator task takes one > title and one project to associate it with. Even a description is optional. > If that project is #Team-X-Internal-Stuff, then the rest can't be bothered. > > If the "overhead" concern also (or actually) encompases a concern about lack > of privacy (i.e. "John to get a headset that actually works in hangouts") > then you can always request a private space for your team in Phabricator. > > The public / private aspect is sometimes tangential, sometimes orthogonal in > these discussions. The test is the following: those suggesting Trello, would > like to have a public or a private board for this? If privacy is relevant, > ask for a private space in Phabricator, where all tasks will be integrated > to personal backlogs and teams workboards, and where privacy settings of > tasks can be modified, being all of them available in the same tool. > > -- > Quim Gil > Engineering Community Manager @ Wikimedia Foundation > http://www.mediawiki.org/wiki/User:Qgil > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > -- Guillaume Lederrey Operations Engineer, Discovery Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] A tool for keeping action items accountable?
the first cause in the causality chain. Digging deeper will probably lead to interesting discoveries. The 5 Whys [2] is again an exercise that I profoundly dislike (for reasons I can get into in another thread if you'd like), but again, its premises are interesting. The digger you dig, the higher the reward... And usual disclaimer, I'm mainly talking about my personal experience here. I don't know enough of the specific context to know if it applies in your situation as well. For all I know, you probably already have digged deep enough in your causality chain and me telling you that tools are not the issue is just me being pedantic and unhelpful (if that's the case, please accept my apologies). [1] http://martinfowler.com/bliki/PrimingPrimeDirective.html [2] https://en.wikipedia.org/wiki/5_Whys >> >> Recently, I have started to create a calendar event for myself at the >> midpoint between retros (at about the 2 week mark). At that point, I email a >> reminder to action item owners. I don't yet know whether this is >> appreciated, and/or if it will help increase the rate of action items being >> completed. >> > I think this is one possible solution. It does put added burden on the > facilitator, for better or worse. >> >> Once someone owns an action item, I trust them to create a phab task, or >> not, as they see fit. Often the action item is "Create a phab task for X", >> and adding a task to create another task would be silly. I think most action >> items are along the lines of "Convene a meeting about X", or "Discuss X with >> Y". > > Yes, if the action is to create a task, it is explicitly that, and it would > be redundant, as you say, to create a task to create a task. Most action > items, as exampled above, are also as stated inline. > > > On Thu, Apr 28, 2016 at 1:25 PM, Kevin Smith wrote: >> >> As a facilitator of (monthly) retrospectives for Discovery, shortly after >> the meeting I have emailed an "action items" reminder to anyone who was >> assigned one. Typically that's a few days after, at the same time the notes >> get put on wiki. Then, during the following retrospective, we start off by >> reviewing the status of previous action items. Similar to what Guillaume >> described, but a bit lighter. >> >> Recently, I have started to create a calendar event for myself at the >> midpoint between retros (at about the 2 week mark). At that point, I email a >> reminder to action item owners. I don't yet know whether this is >> appreciated, and/or if it will help increase the rate of action items being >> completed. >> >> If I create the retro etherpad/google doc a few days before the next >> retro, I might send yet another email reminder to action item owners. But >> I'm not committing to that. >> >> >> Once someone owns an action item, I trust them to create a phab task, or >> not, as they see fit. Often the action item is "Create a phab task for X", >> and adding a task to create another task would be silly. I think most action >> items are along the lines of "Convene a meeting about X", or "Discuss X with >> Y". >> >> >> >> Kevin Smith >> Agile Coach, Wikimedia Foundation >> >> >> On Wed, Apr 27, 2016 at 1:23 PM, Greg Grossmeier >> wrote: >>> >>> That's basically how we do it in releng during our meetings. >>> >>> -- >>> Sent from my phone, please excuse brevity. >>> >>> On Apr 27, 2016 10:20 AM, "Guillaume Lederrey" >>> wrote: >>>> >>>> In another life, I have been facilitating a few retrospectives. Not >>>> here yet, so the context is probably different and this past >>>> experience probably does not apply without the necessary amount of >>>> tweaking. Still: >>>> >>>> The usual rule we put in place with our teams was: "A retrospective >>>> action must have a fairly limited scope and be possible to implement >>>> before the next retrospective". Larger items are not considered to be >>>> retrospective actions, but might be put into the team backlog. Action >>>> items are the responsibility of their owner (if we can't find an owner >>>> for the action, the action is dropped). The facilitator responsibility >>>> is to check the status of those actions at the next retro. If those >>>> actions have not been completed by the next retro, they are either >>>> dropped (if we did not make progress, they are pro
Re: [teampractices] Retrospectives: Getting deep and personal
ny interpersonal >>> issues on these teams. (They do seem to be more emotionally healthy and >>> mature than many teams I have interacted with.) But I don't want to take any >>> chances. And I don't have a ton of experience running retros, so I'm hoping >>> those of you with more experience can provide some pointers. >>> >>> Thanks! >>> >>> Kevin Smith >>> Agile Coach, Wikimedia Foundation >>> >>> >>> ___ >>> teampractices mailing list >>> teampractices@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices > > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > -- Guillaume Lederrey Operations Engineer, Discovery Wikimedia Foundation UTC+2 / CEST ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Retrospectives: Getting deep and personal
Thanks Kevin for the reminder! So here is a short description of the "Adjectives Game": First, note of warning, this game is probably getting deeper and more personal than most team are comfortable with, use with caution. 1) ask the participants to write a list of 10 adjectives that describe themselves, both positive and negative 2) each participant chooses one adjective in that list, writes it on a piece of paper and offers it to someone who shares this trait with him / her 3) discussion / question on the adjective you received 4) go to 2) and repeat as long as necessary Notes: * The idea is that as you only offer adjectives from your list, it defuses the hostility that can come from harsh critiques. If I give you "disorganised plutocrat", you can't feel too much offended as you know I think I share this trait with you. * Even in teams that are fairly opened to non standard exercises, this can be hard to actually execute. We are not used to do direct critiques in a work context. * We work together and we will continue to work together. This means that we need to preserve a work relationship, which makes it harder to do personal critiques. This game can turn into a "I'll only say nice things to make sure I don't offend anyone" (which might also be OK). * This game has a strong "AA meeting" feel to it. * All that being said, with the right team at the right moment it is an amazing way to address deep issues and make the team stronger. On Tue, Oct 4, 2016 at 10:54 PM, Kevin Smith wrote: > Thank you indeed, Guillaume. I have added my interpretations of these to the > Planning Offsites page[1]. It's great to have more tools available! I look > forward to hearing about the "adjective game". > > [1] https://www.mediawiki.org/wiki/Team_Practices_Group/Planning_offsites > > > Kevin Smith > Agile Coach, Wikimedia Foundation > > > On Tue, Sep 13, 2016 at 12:50 PM, Arthur Richards > wrote: >> >> These are awesome, Guillaume. Great suggestions - thank you for sharing! >> >> On Tue, Sep 13, 2016 at 3:16 AM Guillaume Lederrey >> wrote: >>> >>> A few additional thoughts (read brain dump, not much structure here): >>> >>> If we want to talk more about emotions, feelings and all those fuzzy >>> things (which I think we should, it isn't because it is fuzzy that it >>> isn't important!), we usually need to bring different kind of tools to >>> the table. Language tends to steer us into analytical thinking. >>> Language requires us to build structured thoughts and tend to not help >>> all that much to get us started into a deeper discussion of >>> interpersonal issues, or discussion about emotions. I know the "left >>> brain / right brain" is a gross over simplification of how our brain >>> work, but it is a useful metaphor here. Language activate our >>> metaphorical analytical left brain more than our metaphorical >>> emotional right brain. >>> >>> So we need tools to activate our right brain. I have a bunch of them, >>> but none is adapted to a distributed setting. Or at least not without >>> quite a bit of modification. Still a few idea, someone might know how >>> to adapt them: >>> >>> * photolanguage [1][2]: A classic that seems to be more documented in >>> French than English. By bringing pictures into the game, we activate a >>> different kind of thinking. In short, the instruction could be "In all >>> the pictures that are "here", find a picture that expresses something >>> that your team did well this past week". Discussion starts from the >>> pictures. >>> * positioning games: I can't find a link for that one, but the general >>> idea is: "please move along the wall here according to how you found >>> the last feature development went, if you think it was really crap, >>> move to the far left, if it was brilliant, move to the far right, if >>> it was just ok, move in the middle...". Having people physically move >>> around tend again to activate different ways of thinking. I have no >>> idea how to adapt this to a distributed / online retro... >>> * I have an unnamed variation of the rocket retrospective: find one >>> thing that went well, one thing that went bad. Write 2 words (max) on >>> 2 pieces of paper (one piece with what went well, one with what went >>> wrong). Pass one piece to your left neighbour, the other to your >>> right. The person receiving the piece of paper must imagine what that >>> thing was based on the 2 words. While not as radical as the 2 other
