In this blogpost I describe the advantages for a software team of having dedicated ‘chewing the fat’ time whilst working remotely, which maintains the coherency of a team which can be looser than when co-located.

A team not staying in touch enough can fall back to being a ‘Working Group’.

Image for post
Image for post
Cambridge Chalk Pit

Who would want more meetings?

I know, crazy, right?

Who on earth would want to introduce *more* meetings? Well, I would.

With caveats of course. As long as they deliver value; either in terms of ‘work done’ or just in terms of helping or strengthening the team.

Not surprisingly since March my team have all worked from home, I can’t say it has particularly affected the ‘output’ of the team as such, but what I can say is that it has affected the ‘teamness’ of the team — it’s coherency. …

In this blog I argue that as a developer working in a team, the more frequently you incorporate incoming changes the better — problems are spotted quicker and you can adjust your work to fit sooner, saving greater pain further down the track. Working small is beautiful.

Image for post
Image for post

I’ve been a Trunk* Based Development (TBD) advocate for over ten years now, probably from reading The Art of Agile Development early on; but it also is a key part of *really* doing DevOps — in the Accelerate metrics the best performers have changes in production within 30 minutes of a change being made; you can’t really muck around with branches much and achieve that. …

In my previous post, here, I wrote about Allan Kelly’s first two workshops I attended.

This post describes the second two workshops and some final observations.

Image for post
Image for post
Wheat value does this have?

Workshop 3: How do you value a story?

The third workshop contained one of my major memories of the course.

As a developer there’s been plenty of times where we’ve been asked ‘how long will it take to do this epic/story/feature/task?’. One of the *better* ways to answer this is to *estimate* by play Planning Poker.

This is where everyone in the team votes using a set of cards numbered with the Fibonnaci series (often rounded off for bigger numbers) eg 1, 2, 3, 5, 8, 13, 20, 40, 100. …

I have recently taken the opportunity of participating in Allan Kelly’s online workshops on Stories & Value.

I’ve seen a few talks by Allan at various conferences around the UK, and had seen some of the material before, but I found it really insightful, with each week building on the previous.

This was near the beginning of the Covid-19 Pandemic, and Allan was trying out his training in a Virtual form, so Allan was experimenting with the format and technology.

Whilst not a Product Manager myself, I try to take an interest to see the bigger picture and understand the thinking and supporting tools. This course really helped me tie lots of different things together, and has led me to focus even more on delivering value and quickly and incrementally as possible. …

I was given a copy of ‘Uncle’ Bob Martin’s book, Clean Code, about ten years ago now. It seems like hyperbole to say that it had a revelatory affect on my career, however it did; it gave me something of a USP.

Image for post
Image for post
A Legacy, the vegetation alongside a Roman Road

If you’ve worked in the Software industry for any length of time you will have come across Legacy Code both as a concept and undoubtedly as an actual codebase you’ve had to work with. …

As alluded to in my blog on Sprint Calendars, you will have seen the Monday at the start of a Sprint was labled as ‘Tech Day’.

I introduced Tech Day to give explicit permission to the team to tackle tasks that might feel hard to justify to take on in the course of a sprint, but are likely to prove beneficial to that work — Sharpening the Saw as Stephen Covey puts it in the 7 Habits of Highly Effective People.

Image for post
Image for post
An apple a day, or at least a Sprint

This of course includes paying down what Allan Kelly describes as ‘Technical Liability’, as this conveys the concept of it being a bad thing, whereas with it’s normal name of Technical Debt can sound like too much of a good thing to a business or finance person, where debt is seen as an essential tool to be leveraged to the max. …

Image for post
Image for post

Logging seems a really dull topic to blog about, but its actually incredibly important and very easy to do badly — it does require some effort, and you won’t get it right first time (guaranteed).

At a recent discussion about handling issues a customer comes up against, there was a lack of confidence in any logs that a customer was able to supply of they hit a problem; and the standard method was to jump to reproduction and debugging.

Debugging is often seen as the tool of first resort, but really should be the tool of last resort; if you make your code optimised for debugging you’re solving the wrong problem. …

Image for post
Image for post

Around the time I learnt of The Dolphin Model, I had to make visits to what I would describe as a mostly dull, bleak, backwater Government office.

Almost the only interesting thing about this office was a poster on the wall, and that the staff talked about Pointers and Scoopers.

The poster on the wall asked if you were a Pointer or a Scooper, which is why the staff talked in these terms, it also had a cartoon drawing of people stood around pointing at the ‘fresh’ doings of a dog, also in the picture.

The ‘point’ was that many people, when they see a problem, will just stand around and point at it. They may also complain and moan, gripe and grouse, but they won’t do anything constructive about it. …

Image for post
Image for post
Sprint Calendar

In a previous blog I wrote about how I strove to have the Minimum Viable Process; as lightweight a process as I could get away with, only doing as much as was useful; after all the usefulness of planning shows rapidly diminishing returns.

“In software: Planning has rapidly diminishing returns” — Allan Kelly

To aid this I put together a Sprint Calendar to show the regular meetings over a Sprint. They were scheduled to be convenient for all — some of the team tend to arrive around 10, while some get in earlier but leave earlier. …

I have now reviewed sessions for at least half a dozen conferences over 3 or 4 years and for at least two different organisations.

These are my observations from that time, and I offer them as a single perspective; feel free to disagree. There is an element of shedding some light on what goes on during the reviewing process — which can be opaque to the first-time conference submitter.

Image for post
Image for post

How is reviewing done?

First of all, reviews are done ‘blind’ or anonymously for the conferences I have dealt with. The reviewers do not know and are not supposed to know who has submitted each talk. …



@TheCodeCleaner agile consultant, committed clean coder, slayer of complexity and harbinger of tea. Remourner. Now 'part of the team' at @RedGateProdDev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store