Agile is fragile - Tue, May 12, 2020
It is not about the tooling
The tooling doesn’t make a process Agile. It might be a tool to move away from waterfall, but the point of Agile is that teams should have the mandate to change the process to what works best for that team. Scrum is just another regimented way of working. Using Jira is just a different way of putting tasks on a wall.
Yesterday, I did shitty emergent work that wasn’t planned for because our tech is a dumpster fire. Today, I plan on refactoring embarrassing code that hasn’t really done any business logic correctly for two years, but I probably won’t because one of you will ping me to do something else 30 minutes after this. No blockers. /OnlyFullOfCodeQs
Starting with the basics and only adding process when something isn’t working quite right is a better way of moving forward. Something simple as a board with three different status messages such as: “Backlog”, “Inprogress”, “Done” columns should be enough in the beginning. After a while, look into grouping the tasks to represent the bigger piece of work, so you know when you are finished with a chunk of work. But only add it if you really need it. Sometimes the Backlog is the chunk of work and that is enough.
I’ve taken to disconnecting from the meeting after I give my status (which, shockingly, is “yesterday I did my job, today I plan to do my job, if there were any blockers I dealt with them as soon as they happened and didn’t wait for this useless standup”) and so far no one has noticed and/or cared. Only the PM cares about my status and I already know the status of people who I need to know the status of. It has never been clear to me (after a decade of daily standup) what the point of these meetings is. My standup usually has at least 15 people. The way my company uses Jira we end up giving our status on everything twice - once in Jira, once in the standup. Then, if we’re really lucky, our projects also have a weekly status meeting where we get to watch the PM update Jira for 30 minutes to an hour. So weekly I waste several hours talking about the status of my work rather than actually doing work. The PM could just message me and ask me my status and I would tell him and it would take maybe 30 seconds. /Imnotsureimright
A weekly planning meeting is useless if you don’t have externals or a steering group that need to take infrequent decisions on the work you are delivering. If you are not in a situation like this, cancel it or remove people until you are as few as possible in the meeting. The key is to continuosly prioritising to get rid of unneccessary planning meetings and work in the backlog so it is changed as needed. Tickets don’t need to wait for a week to get picked up, that is just crazy. This doesn’t mean the backlog is changed every day as that context switching comes at a cost.
When I was SCRUM master, people legit got mad at me because I started at the exact time, gave everybody <2 minutes (or however long it really took them to say what they did yesterday, today, and problems they have) before asking if they had roadblocks, and if a conversation involved more than one person for more than 30 seconds, it was taken “offline”. So now instead of daily stand-ups, we have daily meetings. 30 minutes where 2 to 3 people can dominate 10 minutes talking about their specific problem while the rest of the team is just sitting there doing nothing. 80% of the people go within 5 minutes, but the other people either turn it in to a TED talk, or tutor session /qwerty12qwerty
Don’t have a process just for the sake of the process. When you are stuck doing process tasks, you are not working on developing the product. Unneccesary meetings stop the flow of the delivery and the overall work takes longer to complete. Remove all impediments.
Continuous iteration should not occur on only development work but on every aspect of the job, including the process.