Thread by @Lisa2May

Okay. LabScrum: the basics.

Scrum came from software development and is now used in many industries. It's a well developed system, with many resources available. We can benefit from existing knowledge and don't need to start from scratch!

LabScrum, developed with collaborators, @AppliedScrum, @Psychologician, and @UO_CTN faculty/trainees, adapts Scrum to the academic research environment. Different constraints and goals require major adaptation while remaining true to conceptual framework and values of Scrum.

Conceptual framework of Scrum: transparency, inspection, & adaptation. Called empiricism (!!). Focus is on the **process** by which we science, not just our output. Once a process is visible, we can see how to improve. The system prompts us "how can our process get better?"

Scrum in a business context is focused on creating great products-- efficiently, effectively, sustainably. At first, I struggled to identify the products of scientific research. What do we as scientists make?

I think we make knowledge (primarily papers, also bi-products like datasets). But we also make scientists, right? (Thx to Yoel Everett for perspective.) We want a system that helps us make great products = high quality manuscripts, AND happy, sane, effective scientists.

Which brings up your question, @eblissmoreau - how to structure meetings with trainees. Traditional meeting structure is 1:1 trainee/PI meetings. The PI is main source of knowledge, PI has to repeat things in meeting after meeting and direct traffic (person X is working...

on a similar project, you should talk to her...). PIs burn lots of time in trainee meetings, wondering if it's the most effective use of time. And trainees can feel isolated and without agency, stuck waiting for help from busy PIs.

Instead...a group meeting structure. Even with non-overlapping projects, lots of value in group problem solving with lab. We increase the frequency/quality of manuscripts by setting concrete work progress goals and providing accountability and problem solving support.

We improve trainee's knowledge of diverse methods and theory by engaging with the details of lab-mates' work. And we practice collaboration skills, which are ** key ** to science as a team sport.

LabScrum meeting structure uses a two week "sprint" cycle: group planning meeting, where individual/project goals are set; 15 min. "stand up" meetings 2 or 3 days/week; a demonstration "demo" meeting where work progress is discussed (most like a traditional lab meeting);

and a retrospective "retro" meeting, to reflect on the process and areas of improvement. Retro is the easiest to skip and the most important! Without a structured time to talk about process, it's often neglected in the juggling of busy schedules.

This makes work more effective, and ** FUN **, particularly for trainees.

There's so much more to say! I'm just back from maternity leave and sometimes even sleeping through the night (!!). I'd love to answer questions- it'd help me outline basics for blog post. Thx!!!!!

@giorgiosironi brought up good points re culture and performance pressure- inspired me to add on to this thread. #LabScrum

Sprint goals are self-identified progress goals, not externally imposed deadlines!

I didn't get that done because...

"...my parents came to town & we went wine tasting"

"...I spent time crying about the state of our world"

"...I helped a colleague on her analysis code"

are all are great status updates, because they're honest! Trust, vulnerability, emotional safety are key to team success. thx to @appliedscrum for coaching on this.

As my brother-in-law @dankreek (software dev w/ years of scrum experience) said "yeah...scrum is cool...but it only takes one as*hole to ruin it."

Culture is of upmost importance. One reason I haven't written LabScrum procedures (also see gratuitous baby pics). Culture of emotional safety & shared focus is key to success of any group. Built in process improvement helps identify elements not working and how to change.

Re: being incentivized to deliver every two weeks - people are more effective with work split into manageable chunks. Two weeks is a good amount of time to get something done (but not gospel). 3 reasons for small, visible, work chunks (stories? tasks? that's a whole other convo):

1) may help identify areas of collaboration - "oh, I'm working on something like that, too. Let's join forces" even when big picture end goal is different, may be smaller areas of overlap (e.g. motion correction, data cleaning, IRB...)

2) may help identify process improvements - "oh, person Y's got a new import script so you don't have to enter all that by hand!" surprising how much reinventing the wheel can be prevented.

3) separation of planning & execution. W/ giant unstructured projects, can get stuck worrying "am I spending my time on the right thing today? Should I be working on x instead of y?" Long term & short term plans help reduce anxiety, allow peace of mind & focus on task at hand.

tldr: this should show up as cheerleading, communication, and problem solving support, not pressure to deliver. If it is pressure, that's a convo for a retro meeting. Something needs to change! #LabScrum