Take your retros off-site

Ciaran Reen — Sat, 29 Feb 2020 15:47:46 +0000

The Retro. This often overlooked agile ceremony is the brains behind the operation, it's the cog that turns the wheel faster, the water that keeps the boat moving. And so many companies get it wrong.

Granted, some of you might be reading this and think 'hey, we're doing good with it' and I guess congratulations are in order. More power to your team or whoever organises it. But I've worked in and seen others work in environments where our poor old friend The Retro gets left behind and buried under stacks of paper entitled 'Time Constraints'.

The Retro should not be left to fester and hide and be grateful for the odd occasion it does come out and see the other agile ceremonies playing. They are a time of reflection. They are a time to cast your mind back in a nostalgic kind of way and ponder the 'what ifs'. That's why they are so important. They increase productivity in the future by focussing on issues (things that are generally fundamental flaws) and performance gains (things that worked, but could potentially be improved).

The purpose of The Retro is to iteratively improve a team's throughput by way of discussion. This is done usually at the end of every sprint, or end of a project, or both. The way teams and businesses get this wrong is seeing that as a meeting. In a room. Sometimes with no windows. You know what a code smell is, right? This is a retro smell. Go to a neutral environment where team members feel comfortable and will open up more.

Key pointers

Here's a list of things to put in place to make your next retro successful.

Take your retros off-site. The most important one and the title of this post. I can't stress this one enough. This isn't your employees taking advantage. This isn't consuming time and/or money. The most productive retros that I've been involved in have been off-site away from the office space. This is an excellent time for building bonds and relationships within the team that go beyond work. Decide a place, be that a restaurant or bar (or even a Weatherspoon's if it's been a particularly gruelling financial month), and go. Grab a table, lay the post-it notes on the table and get the drinks in. Yes, alcohol is included in that. Why? To put it bluntly, because now that developer that was reserved about opening up is now three minutes in to a fine critique on the testing principles of the team. And guess what happens on the back of that? More discussion. And the loop continues. You catch my drift.
Don't set an agenda. Remember this should be informal. Setting an agenda not only limits discussion, but also makes people feel they need to contribute. For example, if an agenda item was set to discuss a new testing strategy and the impact it had, members of the team would feel they would need to contribute to that discussion and prepare before the retro accordingly. Let this happen naturally instead. Assume if a topic is important enough that it will get brought up. This allows for total autonomy amongst the developers, who are now the driving force behind the retros discussion points.
Promote free discussion. Unless a conversation is getting particularly off-topic, let people speak freely and openly about their problems, successes and everything in-between. Stop within reason.
Bonus! Have a 'thank you' section. A bit of appreciation never hurts. Get the team to write down (if they want) anyone they want to thank for whatever reason. 'Spent the day helping me with some code that I just couldn't get working', 'stayed late to rollback a regression', etc, etc. It's nice to know what you're doing is being noticed, after all.

These are general pointers, nothing more, nothing less. I'm not a scrum master, however I've attended enough retros to now realise what makes them work from a developer's point of view. I hope you found at least some of these things helpful. Maybe you do them all, maybe you don't. But you should definitely try them if you haven't. Do it for our dear friend The Retro.

The Retro doesn't like being cast aside or left behind, because when you think about it, it's the only agile ceremony that cares about you.

Written with <3 at forcepush.io

Getting back into JavaScript after a break (and dealing with change)

Ciaran Reen — Sat, 15 Feb 2020 11:44:13 +0000

Digital moves. Fast. You accept that in this industry. I took some time off and came back, and while some things have changed, to my surprise a lot remained the same too. I came back in January with renewed curiosity. But I was also anxious. Taking time off in this industry is dangerous, because for every month you take off could mean a new API to learn, a new library to scour through because the one you used is now considered 'old' coupled with comments like 'who even uses that anymore?', etc, etc. It's like you can't switch off because if you do you will fall behind and will be playing catch up on YouTube at 2am watching JavaScript conferences. So I was anxious this would be me. How outdated were the skills I had? Just how many egghead courses would I have to sit through? It turns out, not a lot.

React, Redux, Express, Styled Components, they're all still there and thriving. There's emerging technologies such as the brilliant XState, Tailwind and Svelte, but these have either not matured enough yet or the community is still figuring them out, because I have yet to find any of them in a job spec. It is still React, Angular, and Vue that remain dominant in that area. I'm grateful for that, because if the paradigm had shifted I would have a lot of catching up to do. This calmed me massively and really secured me mentally for any other surprise changes as these were the core technology choices and what my previous experience was built around.

Still, I had work to do. And I didn't know where to start.

Every programmer in their career will have that moment when suddenly everything just 'clicks' and you understand things you never thought you would. You look at code and you can skim read it better and quicker than a book. Once you progress and move towards senior roles this becomes a natural ability, because you don't have time to sit through 12 PRs a day you develop this ability to notice critical or moving parts that could potentially be a problem. You learn. You develop. But it's something we take for granted. You never think you could then lose that ability, much like you wouldn't lose the ability to read a book. It seems absurd. But we learn to read from a very early age. Coding is something we pick up most of the time in our late teens. Coming back from a complete blackout of any sort of code, I simply had lost the ability to do simple things.

Going through the MDN docs and playing around with some React and XState earlier this week made me realise just how much I had forgotten. To give a bit of perspective and clarity, I couldn't write an arrow function - that piece of muscle memory for those key combinations just wasn't there any more. More nuanced syntax, such as rest parameters, were even harder because I'd actually forgotten what they did and their use cases. It all came back, but it goes to show how much we take for granted when we are exposed to these things day in day out. We subconsciously log them. Our mind reaches out and connects to those things we find interesting. Lose that stimuli though, and the connection fades.

Five years ago this would have been a different story. I remember when I worked at Sky and there were new libraries coming out every other week. New testing frameworks, state management libraries, new patterns for people to try, it was chaos but it was also a load of fun. If that happened now though it would make that transition back into the web world a lot more difficult. As of yet, it's been anything but. It's reminded me to keep up with things though. Read those Medium blogs. Check Twitter for major library updates (core devs usually post them there). Check the job market and track trends. Watch a recent YouTube talk that expands your horizons.

So what have I used to get myself back to where I was previously? I've mentioned a few of them already, but I'll add them here for clarity:

Udemy/Pluralsight/Egghead
YouTube
Interviews
Medium
MDN
Package docs
And finally... a crap ton of coding, including this blog.

That last one is obviously the most important, but supplement it with the others to make sure you're doing the correct thing.

A spare few minutes a day is all you need. But it keeps you in that loop. And staying in that loop is crucial.

DEV Community: Ciaran Reen

Take your retros off-site

Key pointers

Getting back into JavaScript after a break (and dealing with change)