Well that got your attention. Aka sorry about the clickbait.
Context: A large-ish project is using JIRA(*) to manage their work, with varying degrees of success. And they’ve customised their instance heavily. No change was too small, or unreasonable. Over time, their configuration evolved as to be practically incoherent. There’s a parallel with teams maintaining software without paying any attention to technical debt. Things are built on top of other things. Workarounds are invented because it’s easier than refactoring, fixing deep seated faults and moving on. I’m sure most people have had an experience or two a bit like this.
Even your tools like Confluence and JIRA can have technical debt. Remember to pay that back regularly.
When I spent time with them, I came to realise that a significant underlying cause of their tool-based-pain seemed to be rather “simple”. They were not consciously aware of how they worked as a whole. They all knew what their roles were and how to do the day job. They even mostly understood how to work with their immediate neighbours (in a value stream sense). But they didn’t get the whole picture. No-one did. As a result, there was no way of telling whether a JIRA configuration change that would alleviate a local problem would have an adverse effect.
There’s a huge chasm between where they are now, and where they needed to be. Step one was to get back to basics – let them discover how they work (as opposed to how they use their tools) and then help them refine that.
Which brings us to another challenge. It was hard for this project to accept an OOTB configuration – “we do things differently here; we simply couldn’t work with a vanilla installation!”.
So I cheated.
They wanted to work sensibly, so they had great intentions. I tried to use that with a sequence of questions which allowed them to build up a tailored process for them:
- Are you sure you want to use Sprints? Yes! Handy, it allows us to have backlogs, sprints, sprint planning, demos and retrospectives.
- Do you want to visually track what you’re actively working on? Yes! That gave us an “In Progress” column and state
- How do you tell if what you’ve worked on is good enough? We have testers in the team, they work with developers. Before we merge our code, we need to explicitly run tests. That gave us a “Being Verified” column and state.
- When do you close off a story? When it’s accepted by the Product Owner. That gave us a “Done” column and state.
- What happens when things get stuck? We have a blocked column and we put things in there so our scrummaster has a backlog of blockers. That’s another state & column (**).
- When you run your “before-merge tests”, can you start that verification as soon as the developer is ready? No sometimes it takes us a bit of time or we batch up some related work and verify multiple changes at once. That gave us a “Ready to Verify” interim state that testers would pull from.
- Is your product owner available at all times to accept stories as soon as they’re ready? No, our product owner has a day job so sometimes they have to batch accept stories. That gave us a “Ready to Accept” interim state that the product owner would pull from.
The final workflow they were happy with looked like this:
The corresponding board looked like this:
If you squint, that looks like Not Started > In Progress > In Test > Done. Which is pretty standard. But because they, as a team, worked through their process, it was their board. They also thought about a few useful elements, such as pulling work when you’re ready to do it, and trying to limit how much they had on the go at any one time.
Footnotes
(*) I don’t mind the Atlassian stack. It works well enough. But if you go well beyond OOTB then like a lot of products you’re flying without an electronic safety net.
(**) I’m not keen on having a discrete Blocked state as I’m a bit nervous of it being seen as a “rug to sweep things under and start something new”. But this team liked it, and it’s their way of working, so I accepted it.
Amateur Coach 