As with everything, you need to set goals in order to know what you’re striving for and evaluate whether you’re on the right path or not. I tend to set six month goals.

For example, for the past six months, for one of my teams I set the following three big goals.

Better planning before each sprint

Before, each sprint started by dragging the remaining backlog straight into the new sprint and – as I saw it – haphazardly adding things from various projects, trying to maximise the planned time vs available time.

It made the team stressed, because they couldn’t see where they were going. They were doing a lot of context switching, because issues and change requests were added from a myriad of system to fill time gaps. Time gaps based on very rough estimates. Plus a lot of stuff came in from the side. Half of the finished notes on the scrum board were not part of the original backlog, but added along the way. This made the team feel they never finished anything – though they in actuality finished quite a lot.

This was not a healthy situation.

First of all, I wanted to minimize the number of systems and products the team worked on each sprint. Secondly, I wanted there to be a red thread running through our work weeks, so we got a feeling of forward movement and that you actually finished and achieved something at the end of the week. This included better structuring of project backlogs and better specifications and breakdowns before moving in to active development.

As it happened, we ended up ditching sprints all together, at least for the time being, because there were too much uncertainty going into each sprint. The time we spent on planning was simply wasted. Instead we started to plan week by week, trying to set realistic goals for each week. In this process we also ditched Jira for Trello.

Did it work? Did we feel less stressed? Did we finish more things? Hard to say, but we’re spending less time on planning sprint goals that are never met. We’ve definitely had less context switching, although not nearly as little as I’d hoped.

This is something that needs working on in the new year – not so much in the team, but in the overlying organisation.

More planned refactoring

This goal is unmet, because of lack of time. We have too many fires to put out, so the new goal has to address that instead. How to free up more time for the team.

I need to propagate the importance of decommissioning old systems and products. I need to promote a more structured development process.

Again, something that involves the whole organisation. Not just the team.

Get more tech talk going

This might seem strange in a tech team, that I feel the need to get more tech talk going. The team talks tech with each other, but not as a team and not in a structured way. We need a structured, continuous dialog where we evaluate our over all requirements and work patterns. Get some action points down and do it.

This has been started by making time for a weekly, one hour tech meeting. So far we’ve not yet gotten as much out of it as I would’ve liked, but we’ll get there.