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. With a US-based team-member some things have to be only in the afternoon.
Timings of meetings can be used as a method of intimidation in some companies — 8:30am on a Monday morning doesn’t suit everyone and can add significant stress to some people’s start to the week, hanging over them for the whole weekend — but not on my watch.
Part of this is preferring short but frequent meetings over longer ones, as well as the judicious use of the timebox; generally, if a meeting hits the hour mark it’s best to stop there, and come back another day if you really need to.
There’s an exception for more interactive sessions, workshops and retrospectives being examples, which I’m happy to allow an hour and a half.
But really, humans have a limited attention-span, nay, boredom threshold, so allowing them to focus for a short time before grabbing a refreshment, taking a break, getting some fresh-air, whatever.
Another concept I’ve used is ‘Banding’. I remember when (in the UK) Channel 5 launched, they made a big thing of saying, if you turn on Channel 5 at a certain time on any day of the week, you will know what type of programme will be on — so there was always a quiz on at a certain time, ditto the news, ditto a soap.
This idea of regularity, and the idea that our planning meetings are at the same time every week means that it’s far harder to ‘forget’, and reduces the cognitive load of working out what time a meeting starts depending on the stage of a sprint.
Our team has a US-based member so to be inclusive and keep them involved in the team, we have a afternoon standup.
Another constraint is that any afternoon meetings tend to be between 2 and 4 (10-12 for morning ones). Therefore the 1.45pm standup tends to mean they don’t clash with other meetings, without encroaching on lunchtimes too much.
Regular, weekly, Planning Meetings
Planning meetings happen at 2pm on a Monday, to allow our US member to join in. It also happens every week regardless of whether that particular Monday is the start of a Sprint or half way through. This means that the start of a sprint is the Sprint Planning, and the mid-sprint meeting looks further ahead, and make sure we have a sensible set of things to bring in for the next sprint — refinement if you will.
Sprint Reviews and Retros
Showing your work frequently to your stakeholders is central to working in an Agile fashion. To help our stakeholders to attend and for all of us to get the most out of it we use the same idea of timeboxing and banding — on the calendar an hour is shown, but we’ve actually now dropped it down to 45mins as that is most impactful.
As mentioned above, a retro is given 90mins as to really explore what happened and get to the details you need this time; but we try to keep it at the same time each week.
Ten Percent Time
Redgate allows it staff 10% time on a Friday afternoon, to do research, try new technologies and build communities of practice, so that time is blocked out.
Partially with planning only able to happen in the afternoon, but also to allow the team to tackle technical debt and other problems — setting up a test framework for example, or upgrading to .net core, etc — the first Monday of a Sprint has been designated ‘Tech Day’ to work on these sorts of issues. Usually this is timeboxed, but a small amount of monitoring or more urgent response is allowed across the sprint.
Support and Urgent work
Finally, urgent or support work has a dedicated swim lane on the whiteboard, to allow the team to respond to the realities of life. Another swim lane is dedicated to the ‘Product Trio Workflow’ to represent the relevant work that goes on by those around and supporting the team. This gives transparency both ways, building trust.
Line Management time
Many of the same principals can be applied to the time I need as a line manager. I was encouraged when I started to focus this time on one day of the week to help me organise and keep time for technical work. So I set up similarly timeboxed slots for doing formal one-to-ones in a regular slot, and more informal, regular catchups on that day.
Some of the meetings shown on the calendar have actually fallen by the wayside — if you find you don’t need a meeting, don’t do it. Inspect and adapt.
The Trio Standup was myself as Tech Lead, our Product Manager and Designer. This group sets the direction of the team, providing a balance between the influence of the three roles.
Producing a Sprint Calendar helped clarify what meetings were required and gave a visual representation of how the week fitted together.
It helped give team members and stakeholders of when they needed to be where, but it was also a living document, to be updated as required; since I started this blog, I see I need to update it to reflect reality!