There’s nothing like the crunch at the end of a project to find out which processes are really working for you. Agile is a great methodology for approaching a project, but it can easily (and frequently, in my experience) lead to “ticket overload”. This is especially apparent at the end of projects where throughput of tickets is critical as the project rushes towards a hard deadline.
So why the deluge of tickets? Perhaps it’s a sign that something didn’t work earlier on. That QA were onboard far too late, or poorly scoped tickets or poor executed code. Overly ambitious requirements, or fiddly design. All of the above. And some of that is just natural entropy in a project-especially the long run ones where process expands to fill all available time.
It’s not always hard. We’ll do better next time. But sometimes we forget that process is there to help. Not strangle. We forget that we should be hungry to deliver, and delivery is more important than process.
Given a week to deliver something, you find a way to deliver. Any away, whatever it takes.
Given three months to deliver something, process finds a way to trip you up.
I believe in release often. Release small. Real deadlines. Real opportunity for the client to see something to feedback, to catch those changes and design glitches, the bad code or trippy UX. Release every week, twice a week, every other-day. Sit the client down and walk them through it. Show something. Be cool with what you’re showing them. It’s work in progress.
Real agile is iteration. Not invisible sprints without consequence or comment. Breaking a waterfall project into sprint and calling it agile is not agile.