I’ve been a tech lead for 6 years and Agile has given me a lot of imposter syndrome because I can’t seem to make it work for me. The biggest point for our org is to cost work items and realize a consistent throughput for our team on which we can make scheduling predictions.
Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which won’t be fully understood till we’re in the trenches. How do I cost the time it takes to learn how Spanner will handle my design and update architecture accordingly? How do I cost “interrupt driven” work like getting buyoff on a given architecture? One of my OKRs was literally “Create a security model for a new foundational technology that is acceptable to all integrators, follows Google Cloud best practices, and can be represented in Kubernetes.” How would you break that into (bi)weekly sprints? You don’t even know what work you’ll have to do until you go to a committee of stakeholders and get told where you have to go back to the drawing board.
See, this is about agile going wrong.... back in the early days of XP, a term started popping up "Brain Engaged", meaning that you don't blindly follow perscribed processes. The manifesto tried to capture this in somewhat frilly language. So be agile ( not in the dogmatic process sense of Agile with a capital 'A'). You have to do something like "create a security...blah blah". You don't have to do anything bi weekly, what you need is a way of of doing that where you can get feedback as soon as possible, how do you iterate through possibilities and arrive at a good decision? how do you involve the people who need to be involved in a way that you get good contribution? How do you make it so it is robust, how do you progressively work towards the goal while minimizing risks and failing fast? If nothing else, the core of agile is feedback loops and communication with the various people involved at a rate that people need.
To expand a little, since the org wants accurate estimates we need to accurately measure throughout and the total quantity of work. Though throughout trends stabilize pretty quickly, the system falls apart when one task reveals another. Accurately breaking down and costing every sub task at sub-week granularity for a multi-year project is an almost insurmountable task. It requires effectively doing all the work in your head.
I’ve seen one compromise and benefit to the system:
Compromise: push back on scheduling until the date you give for coming up for a date of completion. This works best during the final phases of development.
Benefit: with weekly throughput info, it’s easy to tell if someone is trying to do too much in a sprint.
Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which won’t be fully understood till we’re in the trenches. How do I cost the time it takes to learn how Spanner will handle my design and update architecture accordingly? How do I cost “interrupt driven” work like getting buyoff on a given architecture? One of my OKRs was literally “Create a security model for a new foundational technology that is acceptable to all integrators, follows Google Cloud best practices, and can be represented in Kubernetes.” How would you break that into (bi)weekly sprints? You don’t even know what work you’ll have to do until you go to a committee of stakeholders and get told where you have to go back to the drawing board.