#23 - Link Roundup, 3 July 2020
Making space for disagreement; Avoid burnout and start saying "No"; Agile vs Waterfall and Risk Management
Half the year has passed, it’s Canada Day week here, and it’s the last day at our teams organizational home for the past four years before moving to a neighbouring institution. It’s been a good opportunity to take stock, and our team has some suggestions for what we should do differently starting afresh next week.
And I’d definitely welcome input from you, too! A reminder that all tracking is disabled on this newsletter — I rely on the old-fashioned approach of you emailing me to tell me what is interesting, what isn’t, what you’d like more of, and what you could do without.
So with that, on to the — somewhat shorter for the holiday week — link roundup!
Making Space to Disagree - Meg Douglas Howie
I know I keep hammering on this, but it’s such an important topic, and people keep writing good articles about it.
In our line of work our team members are generally experts or becoming experts in various areas, and if they’re not comfortable speaking up and disagreeing — with each other, or maybe more importantly, with us — not only are you losing incredibly valuable input, you’re also running the risk of eventually losing them.
There’s a number of techniques in here for soliciting input in early stages of discussions that avoid either-ors or active disagreement - ranking options, placing optoins on a two-dimensional spectrum, and approaches that are more like brainstorming. That allows people to weight options or express pros and cons differently. And as a benefit, the conversation automatically focuses on the more subtle/interesting tradeoffs rather than on the parts where there’s consensus and so no further conversation is really needed.
The Work-Centric Standup - Leeor Engel
A lot of us in resarch computing run daily standups of one sort or another. We use the “people-centric” status update approach - what we did since the last standup, what we plan to do until the next, and if we’re blocked; this article advocates for the more kanban-board focussed approach, where you run through the list of tickets/stories/stickies and talk about what progress has been made.
There good arguments either way. What approach does your team use? Do you know anyone who switches back and forth between approaches?
Managing Your Own Career
We’re all still being asked to do an awful lot, and between supporting our teams during a pandemic and while confronting issues around systemic discrimination, and pressures from our own management and stakeholders, things can be overwhelming. This article is just a reminder that saying “No” or “Not now” is almost always an option. Your team has priorities and neither you nor they can or should be loosing focus on those for every incoming request.
Agile or Waterfall; a risk management perspective - Alfredo Motta
There’s been lots written about agile vs waterfall, and most of us operate so much in an agile mode that we don’t really think about it any more, but I think Motta’s article is a very clear description of the what and why of the two approaches, and a good reminder that there are absolutely places in research computing where waterfall is the right choice.
The Chaotic/Complex/Complicted/Obvious distinction is useful:
The path is… There are … practices for this work The right approach is Obvious Best Practices Waterfall Complicated Good Practices could go either way Complex Emergent Practices Agile Chaotic Only Novel Practice Agile
In research computing we’re often in the complex/chaotic side of things, but not always - if we’re setting up a new set of webpages or rolling out database migrations, setting up a new cluster, or designing processes for our teams to follow, there are best practices and using those and having a more waterfall approach to things can be perfectly appropriate. Most of us understand this instinctively but it’s good to have these distinctions explicitly in mind.
It’s always reassuring to hear about other teams’ computing and data integrity issues. Canadian Tire is a popular retail store in Canada; in one geographic cluster of the stores, for a little while last week, every single purchaase rang up at the cash as a Mr Potato Head due to a “downloading error”.
AWS has a new ML-powered tool that looks through your code for deploying on AWS and finds your most expensive lines of code. No, not expensive like CPU/memory intensive lines - expensive like money intensive.