Balance Programming

Retrospective 1-26

One of my original goals with this blog was to manage 26 posts in 6 months. Here I am in 3 months. Well done me. This one is both a retrospective of that achievement and my thoughts about retrospectives themselves. I think they’re a good idea but… I’m not entirely sure they work.

Retrospectives

Maybe you don’t need this but I didn’t do it “properly” until my last job so let’s cover the basics. A retrospective is part of SCRUM framework. The team’s time is organised into sprints, say, two week blocks. In each sprint the goal is to complete an agreed set of tasks. At the end of the sprint you have a retrospective meeting that looks back at how it went. Everyone in the development team contributes to the meeting, looking back at what’s been done to help do it better in the future.

The JIRA template for the meeting I used had the questions “What did we do well?” and “What did we do badly?”. To me these are the wrong questions. I think they’re harder to answer than they need to be and don’t cover enough. How about these instead:

  1. What happened?
  2. Was it good or bad?
  3. What to do about it?

The first is easy, each person describes the sprint from their point of view. That’s probably going to be the tasks they did or didn’t manage to get done. The reason to have it is because it is easy, no decisions to make. It also acts as a useful summary for everyone both at the meeting and for the record.

The second is almost as easy, for everything that happened was it good, bad or somewhere in the middle. Tasks as expected, that’s neutral to good. Added build caching halves build times, that’s good. Added new unit tests and uncovered a bug, that’s both good (that the bug was found) and bad (that it’s been hidden up till now). The roof leaked and someone’s machine needed replacing loosing 2 days, that’s bad. I think this is easier to answer and gives better coverage than “What did we do well?” because we don’t care about responsibility. The roof leaking isn’t the teams fault but it’s still affected the sprint and it’s still bad.

The third is the harder question, how do we get more of the good and less of the bad in the future. I think this is in the SCRUM framework but it wasn’t on the JIRA template, it was probably meant to be implicit. If build caching can halve build times does everyone get that for free? Do they have to install something? Is there a setup script that will install it for them? If someone’s machine needed to be replaced how long does it take to set up their new machine? Again, a setup script might be able to install everything they need for the project. Should making a setup script go on to the backlog? And while the team probably can’t control this, can we move to somewhere without a leaky roof.

I think the third part is where retrospectives are most likely to fall down. The team can recognise good and bad things but aren’t able to translate them in to useful actions. That can be because improvements are never given priority in the schedule. It can be that there isn’t enough impetus to do something with the information. Try to fight it. If you keep having the same problems you’ll keep suffering. If that’s the problem try to find the smallest step that might help.

Meta-retrospectives

If you’re just looking at the last sprint then you might not notice bigger patterns. I can see a few options here:

  • Relying on memory: As problems crop ask yourselves if you’ve seen them before. This is probably the default. It is easy but you might miss stuff.
  • Have a meta-retrospective: Schedule a retrospective of retrospectives every, say, 3 or 6 months. This doesn’t have to include the whole team. It feels like the most work and I can imagine some people not liking the idea. Looking through everything in the previous retrospectives would be the best way to notice patterns.
  • Making a task of it: Give one or two people a normal task to look over 3-6 months of retrospectives. They can summarise progress and report back at the next regular retrospective.
  • Regularly looking back: At the end of each normal retrospective take a few minutes revisit earlier retrospectives. It might include the last one to make sure actions were taken and one from 6 months ago to see if we’ve learned lessons or are still making the same mistakes.

I don’t think a lot of time should be spent at this meta level but it should help if there are problems carrying through on ideas.

Posts 1-26

This is my line up for the last few months:

That breaks down into:

I think it’s been an interesting range. With only a couple that I might classify as filler, although still useful. I’ll go back and take out the code-review and markdown tags as they seem a bit specific. After a slightly uneven start I’ve gotten into a Tuesday / Thursday release schedule. I’m happy with that for now.

This blog is giving me a bit of extra motivation to look in to these things. It’s easier to get through a big software book if I can come up with an associated post. I’d like to write some larger coding examples to help illustrate some ideas. Maybe in the next batch.

What can be hard trying to avoid just saying how I do things. This blog is meant to encouraging thought about how to balance programming. I think my way of doing things has been good but that doesn’t mean it’s the best or right in every situation. I’ll try and keep my mind open to other ways of doing things. Often it’s about getting the right way to approach a post so I can mention more than just one solution.

I jot down potential future posts and should have enough for the next “sprint”. Topics may include:

  • PowerPoint for now or later?
  • Working remotely
  • The JIRA railroad
  • The perfect IDE
  • Journey, destination and story
  • Reasons for why
  • Searching for design
  • How NASA writes space-proof code
  • Rust review
  • Data-oriented design
  • SCRUM vs Agile
  • Game Programming Patterns
  • The taste test

Posted

in

by

Matthew

Tags:

, ,

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *