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’.
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.
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. …
This post describes the second two workshops and some final observations.
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.
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.
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. …
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. …
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. …
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.
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. …