Just do it (or maybe not)

Posted in: Agile, DMC team

In the last 12 months, the DMC build team has changed dramatically. We have a host of new faces, all bringing fresh ideas, different approaches and impetus to the team.

Watching the newest recruits adapt to how we work here at the University of Bath is fascinating. The more familiar they become with our processes, the easier it is to triage the myriad things we're required to do every day.

This got me thinking – how do we organise and manage our workloads? Where do all these tasks, jobs, fixes and tweaks live? When do they actually get done?

During my people watching, I've identified four opportunities for 'getting things done':

  1. User stories.
  2. Developer Development.
  3. One Hour Upgrade.
  4. <redacted>

1. User stories – an agile standard

As a…
I need…
So I…

The build team use Pivotal Tracker to build our backlogs and icebox. If there's a genuine user need backed up with data, then we make a story, add some detail, identify scope and add thoughts for future consideration.

New stories usually end up in the icebox waiting to be prioritised. Once in a while, depending on a story's relevance to the current sprint, it could go straight into the sprint backlog. On very rare occasions, they are dropped straight into the sprint.

Placing stories into Pivotal makes the work immediately visible to the rest of the team. The bulk of our day-by-day work in the build team can be found in Pivotal, making it relatively easy to get an overview of team direction and productivity levels.

So stories cover the prioritised, road-mapped jobs that simply have to get done. But what about the annoyances, the bits and bobs, the opened bag of continental salad that sits mouldering at the bottom of the icebox never to be finished? How do these things ever get done?

2. One Hour Upgrade – nimble fixes

We’ve written about our One Hour Upgrades before. Go and have a look at what we get up to. I’ll wait for you.

One Hour Upgrade (OHU) provides an opportunity to fix small-scale stuff that does not warrant a sprint story. It might be a tiny tweak improving an aspect of our accessibility, updated documentation helping site admins work more efficiently, or fresh content for a long-forgotten but well-travelled page.

As long as it can be finished (in OHU terms, finished means ‘The work is done. I would like someone to review this.’) in under 60 minutes, then it’s fair game.

One Hour Upgrade works best when the tasks are:

  • story fragments from tasks in the Pivotal icebox
  • documentation refreshes
  • low-priority bugbears
  • small enhancements to established functionality
  • content iteration

Occasionally we also end up with stuff like 'dragon knitwear' too.

3. Developer Development – bolstering professionalism

Most Wednesdays, the build team head out of the office to spend a couple of hours broadening our skill sets, learning new things and exploring new software and technologies.

The official line is ‘no story-related work’ as this is professional development time, pure and simple. However, on occasion, discovery work done in DevDev will lead to a new story in the Pivotal icebox or provide the spark for a One Hour Upgrade. In itself, Developer Development isn't an opportunity to do work, more of a chance to identify things that needs to be done through other channels. An excellent example of Developer Development acting as a catalyst for new stories in the icebox would be our ongoing investigation into visual regression testing.

4. Just do it! – hidden work

"I’ll just sort that now. It’ll be easy"

It's frowned upon, but hidden work can creep in to sprints. The little fixes and tweaks made that are out of scope for the story you are working on often result in undocumented work and bigger problems down the line.

Hidden work can also manifest when jobs and tasks are dropped into a sprint without warning. We try and mitigate this by creating stories capturing the time and resource needed to get the job done.

Keep on doing what you're doing

So far, it seems that the new members of the team are adapting well to life at the university. Sprints are productive and we're meeting our goals with impressive regularity. Time spent in One Hour Upgrades and our weekly Developer Development sessions are paying dividends, with small improvements to the site being made continuously alongside sprint work. I look forward to seeing how we can continue to hone delivery as our processes mature and evolve over the coming months.

Posted in: Agile, DMC team


  • (we won't publish this)

Write a response