Anyone who knows me knows that i’m not a huge advocate of Agile.
There’s lots of reasons for that, from the fact that it prevents folk from defining actual requirements in favor of vague stories (which makes testing and documentation harder), to using arbitrary points without accounting (ironically, those points are VERY attractive to accountants who see them as a measure of productivity, even though they’re never meant to be that), to the fact that the SCRUM master is inevitably a manager who has a strong stake in productivity and not someone like a lead engineer who understands complexity (which makes it harder for engineers to push back against features). Agile also works for well defined tasks or simple work where engineers are interchangeable. This almost never matches reality.
Still, tracking and reporting work is valuable, and there are tools that can help with that.
So, how does a modern team do that?
Hell if i know. i’m not a productivity specialist or some sort of efficiency expert. i’m just a guy that builds and supports back end systems, and has done so for a very long time.
i can tell you the way that our team currently does things, or at least, what works for me. It might work for you as well? Who knows. The fact is that trying to use a single system as a universal solution is like trying to build a log cabin using only Swiss army knives. It might theoretically be possible, but there’s going to be a lot of sadness and used bandages before you’re done.
Each team is usually made of a bunch of folks with specific skills. Some might be really good at solving odd problems. Others might be fantastic at finding hidden bugs. A few might be top notch at optimizations. They’re not cartoon assembly line workers (and even there, you’re going to need training before you’re told to go add wiring harnesses this week and installing dashboards next week). So folk tend to do a lot of the same sort of tasks, partly because it’s comfortable, and partly because the inverse Peter Principle means that nobody else wants to do that job.
i kind of view it as Air Traffic Controllers (mind you, my knowledge of ATC folk comes from watching movies like Pushing Tin so it’s probably hilariously wrong, but it’s what i know). Each controller has purview over a set number of flights managed as a stack. As a flight leaves their area, it’s removed from the stack. As flights leave their area of control, they’re removed from the stack.
Developers tend to work the same way. There might be multiple tasks they’re working on. As they complete tasks, they get pulled from their stack, as they get time, they might add more. Since developers are a lot like async functions, there can be times they’re blocked, so having a bunch of tasks on hand can keep them from surfing . The downside is context switching, but some folk are better than others.
We use Jira (or really, any bug tracker system) for how we say “we’re working on this” and “this is done/blocked”. It’s how we communicate to ourselves and up the chain. Tasks are associated into groups, which are collected into Key Results, which are assigned to Objectives so that execs get pretty dashboards with blinky lights they can put into slides that result in us getting paid.
Senior Devs are kinda responsible for breaking apart the Key Result into groups and tasks, again, so that the work gets properly tracked. If another group has a requirement that demands some feature, that group gets prioritized appropriately. (We also don’t do crap like “Planning Poker” or whatever. Look, the person who’s doing the work absolutely knows what the effort is, unless they’re brand new to development. Getting a bunch of other people who may have zero context to make SWAGs ain’t gonna help. If y’all did auditing of tickets and points you might realize that, but i’ve never read about that in any article or done that in any retro, so yeah, chances are you’re not doing it either.)
Is it a fantastic solution that will solve all you problems?
No, What? Were you paying attention? It’s just how we do things. You will have a different solution because of reasons. Still, this works for us and generally persists longer than whatever Agile system gets inflicted on us.
