A Pointless Retro?

I’m a big fan of the Retrospective. I have always thought of it as the most valuable of the Ceremonies. It’s a fantastic way to get a team to open up about what’s bothering them in a way the stand-up’s “blockers” question just doesn’t allow. It’s a safe environment for them to raise anything at all that’s bothering them.

I ran a retro today for the end of my new team’s first sprint, and for the first time I almost wish I hadn’t bothered.

The team has nine members, including me. One was on a course (and missed it), one can’t get into the building yet (and was on the phone), one was working from another building (and was also on the phone) and one was travelling (and missed it). Five out of nine, not a great result for my the first run of my favourite Ceremony.

During the sprint, roughly half the team were out for roughly half the time, some of which was expected and some of which wasn’t. The result was that, while some Good Work has been done, we’ve not delivered much. The reasons for this non-delivery are immediately obvious to all concerned and the sprint is being flagged as “successful” rather than “failed” largely because the team did all the right things at the right time and calling out a failure in the circumstances wouldn’t add any value.

The problem with today’s Retro was that there wasn’t really that much to discuss. One team member isn’t a fan of Retros at all and was very vocal about how the whole thing is a waste of his valuable time (he’ll learn) yet contributed the most in terms of things to get sorted out. “What went well?” was met by complete silence – nobody had anything to call out for protection in future sprints. “What didn’t go well?” had only a couple of token issues: internet connectivity is patchy from time to time and could we arrange some walkthrough sessions for the newbies.

Where I take satisfaction, however, is that the Retro was fitting for the Sprint. As I wrote earlier, in an ideal world, we’d have waited a week or so to start the Sprint and we would have used that time exclusively to make sure that the stories were in a much better state before starting. Outside of that rose-tinted fantasy, however, the team now understand all the things I expect to happen in a Sprint. They’ve attended all the ceremonies, even if only in a half-hearted manner, and doing things better in the next Sprint won’t come as much of a shock to the system.

To answer my implied question in the title of this post, no, the Retro wasn’t pointless. Not as rich and rewarding as many other Retros I’ve run, admittedly, but fitting for the Sprint and the Team and a good use of half an hour of our time, definitely.

Running before walking

New job, new product, new team, let’s make sure we start as we mean to go on and Get This Right! Right?

Wrong.

This time.

The product might be new to me, but it’s been around for about a year or so. The result of a project that ran out of budget somewhere during Alpha and was put live anyway, there’s already a long list of things that the users hate and that need to be fixed, but almost none of the entries in that list stand up to any kind of quality review for a Story.

Most of the original team have left and half the new team only were only due to arrive during the second half of what became the Sprint, so with the backlog in such poor shape, we were nowhere near ready for a Sprint to start.

I started a sprint anyway.

With a couple of days to run this sprint, the burn-down looks like this:

Screen Shot 2016-04-15 at 10.57.47

That big spike on day 2? We added one Story to the Sprint because it had one Task still open even though the Story itself was closed. It brought loads of work with it (work goes up) which was already done (work goes down again).

That cliff on the right-hand end of the red line? We dropped a Story into Sprint 2.

The long expanses of horizontal lines on both red and green? People weren’t used to updating their tasks, so didn’t.

Two people joined the team on April 12th. One of the existing people went on paternity leave on April 8th. Two people were on holiday until April 11th.

If our goal was a pretty burn-down chart, starting a Sprint was a terrible idea.

My actual goal was to highlight to everyone that would listen that getting Stories into a good state before you start a Sprint is important. Not because it lets Jira draw a pretty graph, but because the ugly graph is a symptom of a team that doesn’t know what it’s supposed to be doing. It’s clear from the interactions I’ve seen between the PO and the developers that priorities have been changed on a day-by-day basis, that nobody really has a handle on enough of the detail of any of the work and that I’m going to be gainfully employed here in this role for several months to come!

The Honeymoon Period

I started a new job just over a week ago.

The new team, uniformly, are lovely. My Head of Function is a delightful mix of welcoming and supportive. The work (software used internally in government) is interesting, the project (rescuing a partly broken and thoroughly hated product that resulted from a failed earlier project) challenging, the tools (jira, a MacBook Pro to my own specification, O365, Trello, Slack, Jenkins, etc) effective, powerful and current-century. I’m in Heaven!

Except, of course, this is the “honeymoon period.” The team are about half new, half old hands, so everyone’s still in the cautiously polite ‘norming’ phase. The project is a freshly-kicked-off reincarnation of something from last year, so the stakeholders have easily-met, low expectations. We’re still hiring to fill out the team, so the workload for me as a Scrum Master is still relatively low – nobody’s bringing me much in the way of blockers yet because we don’t have that much in the way of work yet.  Honeymoon.

Still, it’s been over a week and nobody, yet, has asked me to do anything blatantly stupid or obviously pointless. It bodes well (or at least, better than my previous role) to have lasted this long in that happy state. And there have been a couple of frustrations around the time it’s taken to get a security pass of my very own, rather than having to be escorted around the place on a V-badge and a couple more days working from home as a result than I would have liked this early on. Nowhere near enough to dent my mood, which has been, frankly, amazing for the past seven working days.

I can’t remember the last time that was true.

Today, for example, I was happily playing with Jira, reviewing who’d done what (in terms of Jira stuff, not in terms of ‘real’ work) to work out who needed what help and in what priority order, and thinking about which of our ‘almost ready’ stories to take to the grooming session, and wondering how I go about booking a room to schedule that session and generally wallowing in Scrum Mastery Goodness when I happened to switch to the screen on my Mac that still has the clock at the top and realised that I could have left over an hour ago and probably should have left at least half an hour ago. It reminded me of something I think I’d forgotten somewhere in one of my past three or four jobs:

Working on something you enjoy doing, with tools you enjoy using and people you like spending time with isn’t “work”.

You get paid for it, you’ll catch hell if you mess it up, and you’ll probably end up putting yourself under more pressure than anyone else could ever manage, but it’s not “work.”

I told myself this afternoon that it’s just the honeymoon period. I told myself it won’t last. I set myself up for that moment when disappointment strikes and it all just becomes “work” again, but that’s just dumb. Maybe it will. Maybe it won’t. Worrying about it, becoming cynical ahead of it, is pointless. Bringing that kind of negativity to the office is a terrible idea, one that will only serve to hasten the end of this state of occupational bliss, when the truth is that I can’t remember being happier in what I do and how I do it.

Yes, maybe it’s just the Honeymoon Period. I plan to enjoy every single day of it as if it’s the last, and in doing so perhaps it’ll last a bit longer than it otherwise would.

Print(“Blog Time! Round \(++failureCount)”)

(So much for good intentions. This sat in my Drafts folder on here for almost six weeks!)

I’m a self-employed contractor. I don’t have an “Employer”, I have a “Client”. Today I decided to leave that client and take on a new one.

I’m not an employee. I don’t have to do all that tiresome “performance management” stuff that employees have to do, because I’m a contractor. I don’t get holiday days or sick days or employment benefits of any kind unless I pay them to myself from my own company.

So why do I feel so guilty?

My current client is a large, high-street brand name with a significant digital presence. They’re probably not the best at what they do, but they’re good. Customers seem to love our work. The client looks good on my CV (contractors still need CVs, just like employees).

So why am I leaving?

I’m leaving because, in my current client’s organisation, everything is hard. I’m not one for whining. I’m not having a go. It’s not that the team, the department, the project or any of the things that cause many people to become disgruntled and leave organisations.

It’s because Everything is hard.

Not “some things are harder than they should be.” Not “this thing I’ve been trying to do for ages has continued to be impossible because of stupid reason X.” Everything I’ve set out to deliver over the past two years, I’ve delivered. More than half of it on time. More than half of it with quality far higher than the norm for the environment. But every little thing, every step of the way, is hard.

Everything you want to achieve requires significant effort, buy-in from stakeholders, process, paperwork, approvals galore, obscure regulations that you didn’t follow because nobody ever mentioned they exist, entire processes that have remained undocumented for YEARS, including “Deployment into production”, which run differently every release cycle because there is literally NOTHING written down and the “right” way to do something depends on which member of the deployment team you ask, a separate entire function called “DevOps”, who are neither developers (with the power to change or test code) or Ops (with the power to investigate and correct operational issues), I could type all night.

I come from an Agile background. I’ve had years of experience Inspecting and Adapting. On my CV, right near the top, it says “I like to fix broken stuff.” I’ve spent two years mashing my face against the bare brick walls of “because that’s how we’ve always done it” or my favourite from a divisional COO recently “do as I say, not as I do” and it’s time to stop.

Time to walk away. Time to remind myself that they’re not my Employer. They’re my client. They pay me money to do stuff for them, and if I don’t want to put up with this, I don’t have to. They don’t own me. I don’t have to give three months’ notice and slog on to the bitter end. I’m a contractor. My notice period is twenty-eight days. Four short weeks.

On Monday, I have an appointment to tell my Assignment Manager that the clock has started ticking.

Hello (again) world

This isn’t my first go at blogging and it probably won’t be my last.

Last time I tried, I think I made it to four (weekly) posts before I ran out of steam.

Let’s see if we can beat that this time.

I’ve learned recently that a good way to develop a positive habit is:

  1. Actually do the thing you want to turn into a habit
  2. Decide beforehand how often you want to do it
  3. Keep an honest record of when you do it and when you don’t
  4. Don’t get too hung up on the failures
  5. Do make a point of celebrating the successes, however small

So today, I’m restarting this blog. There’s a bunch of change coming my way in the near future and I’m pretty sure it’ll do me some good to write about it as it happens. If anyone else finds it useful, interesting (or even “at all”), then even better.