Or why we stopped caring about "Effort" and strict Agile.

No two people, no two teams, will agree on what “Agile” means.

I should say before I get into the main thrust of this blog post, that just because this works for us, it won’t necessarily work for your team. Though you may want to read this, bring it up in your team, and decide what “Agile” means to you and what workflows you are doing because they’ve always been done, if you’re not using that data within the team, or could be using that data more effectively.

“Agile” as Guidelines

‘They’re more what you’d call “guidelines” than actual rules’

Our Agile process should adapt to the team’s needs, rather than hinder their growth or efficiency by constraining them with a fixed set of rules.

A real-life example of sticking to the Rules:
In an old job, we did “strict” SCRUM, recording effort, estimating complexity and time, performing repeated retrospectives to hone the team to know exactly how hard things were and how long they would take. From that, we could plot velocity and plan SCRUM from that. However, this ate a lot of time, and we probably didn’t need to be so strict, EXCEPT in that team we had an external client we updated every 2–3 weeks on progress and had to show concrete data to them to prove our workflow and explain any delays.
On the flipside, we could artificially inflate or change our velocity with easy tasks to buy ourselves time to complete larger tasks we deliberately underestimated. That didn’t help the team at all because we couldn’t trust our own estimates, but it was needed to keep the client happy, which in turn reduced pressure on the team.

Now back to my current team at ClickTravel;
I’ve spent a lot of time this week thinking about the “software” side of Team leading, how to make the lives easier of my team not through any code or automated pipeline, but simply by changing our internal practices.

Changing how we use JIRA and Asana

My Product Owner and I spent a whole afternoon talking through our use of JIRA/Asana, how we felt each should be used and then going through and actioning those changes to JIRA.

This resulted in clearing down our JIRA backlog of over half the tasks and tying a lot of the weeks/months old Technical tasks or Improvements which we hadn’t had time to do, in with upcoming Asana cards. In future allowing us to deliver new Product Features whilst simultaneously tidying up tech-debt or implementing other improvements, we’ve spotted within the codebase.

After discussion with the team, we collectively agreed that our JIRA dashboard should contain only work in focus, or expedites, and anything planned but not in focus would sit on the Flights Backlog. As a team we can then organise the backlog in Priority order, meaning if anyone is off on a planning day, or someone finishes focus work early, the team can look at the backlog and simply pop some tasks off and into the dashboard. Our snippets meetings then become times we can sit down, run through what we’ve done, and looking at the ordered backlog and simply deciding how many tasks we think we can pop off onto the Dashboard.

Our dashboard has become much cleaner and obvious what needs working on that week, and our backlog similarly can become a team product to keep clean and ordered, so when work is to be done, the team knows they can simply take off the top of the backlog.

‘Gotta go Fast’

Stopping caring about “Effort”

Cycling back round to the first point, during our discussion about using JIRA within our Kanban cycle; I raised that during the week, people should move cards to “LIVE” with Effort recorded, but not move to DONE, as that is something we’d review as a team during Snippets and use to inform our weekly achievements.

• Which has the added side benefit that we don’t have to remember what we’ve achieved, anything we have achieved is in “LIVE” waiting to be moved to “DONE” at the end of the week.

But with “Effort” I was asked, “Why?”, at which point we paused.

“Why do we record Effort?”

Well in Agile theory to measure our velocity against our estimates.

“But we don’t do any estimation of story size, as story points, within our Kanban flow, nor do we measure our velocity.”

So what was the point in having to record effort, or more importantly, having to remember to record effort, or someone explicitly having to spend time asking people to record effort days after the fact?

Within our team, the answer was a resounding: None.

So we stopped caring and removed it from our JIRA cards (we set up a team-specific ‘screen’ in JIRA because there were some fields we wanted adding just for us, therefore it was relatively trivial for me to remove the ‘Effort’ field from our ‘screen’).

That’s not to say recording “Effort” is a bad thing if you are using the data you collect within your team to inform your planning.

Nor is any of this to say that our Kanban flow, JIRA and Asana use are the one true way, quite the opposite.

There is no One True Way; Agile should work for you, rather than you working for it.

If sticking to a tried and tested flow works and improves your team’s efficiency, rather than not, then don’t change just because I wrote a blog post, that’d be the worst outcome I’d want!

Simply think about what you use your Issue-tracking tools for (such as JIRA/Asana) for;

• How you use them and is there anything you’re doing because they’ve always been done?
• Is there anything you could change or remove which would actually save you time in the long run?
• Or do you want to add in processes such as Estimation because measuring velocity will help you plan your project timescales more effectively? There’s nothing to say we won’t change our minds down the line and add in processes we’ve removed or some other “Agile” process.

‘There is no one Agile Methodology to rule them all’

Tim Knight
Flights - Tech Lead
Click Travel