We are all agile software developers now. Never have I met a manager who didn't want their team to work agile. There are those who follow Scrum to the letter and those who prefer their own interpretation. No matter your preferred way of working, here are the few fundamental mistakes I tend to target first.
No empiricism. Knowledge comes from experience and making decisions based on what is known. Traditionally products had predetermined features where the schedule and cost were estimated. Unfortunately, no amount of up-front analysis can guarantee a valuable product. Expectations of software are high and the subjective nature of humans requires finding a delicate sweet spot. Instead discover as you go. Use empiricism to find the few features that resonate with users and hone them.
No north star metric. Predetermined features are so tempting as they, incorrectly, provide a checklist of features that measure our progress towards succes. We fear losing control without it. Having one metric that strongly correlates with the value of the product allows us to regain control. This north star metric is an anchor point to sustainable growth and is crucial to determine the success long after features have been made. Bonus points when extended with a shortlist of feature metrics and technical metrics (such as traffic, errors, latency and saturation) to drive decisions.
No failure. New teams often feel the need to allocate time to prepare tools, analyse features and a way of working. When you say you need a sprint zero to prepare everything, then you are avoiding failure and have already lost the game. Try to get that small increment out there. Forget about preparations. Take one day to brainstorm a single feature, write tasks on post-it notes and get some results to build momentum. Finally, deploy it manually and see what you can automate on the remaining days of the iteration.
No flow efficiency. We like to be busy. We like it so much that we never pause to see whether it has a positive impact on our productivity. Move away from always-busy experts and handoffs towards a team working together to finish a feature. It should be an exception to be working on two tasks. Keep pull requests small and review them within the hour. If blocked ask the team whether anyone needs help or can help, read an article to stay up to date on the latest technology, improve the documentation or simply relax a bit to avoid burnout. I highly recommend Johanna's series for a deep dive in the comparison of resource versus flow efficiency.
