Note that ALL of these can be summed up in one phrase that I tell my teams often…
TIGHTEN
YOUR
FEEDBACK
LOOP
This is literally the key to life (besides 42) and everything. Want a better relationship with your partner, pet, friends, boss, code, family then tighten the loop.
- small changes, fixes, additions
- tests, optimizations, refactoring
It’s what you do to move forward iteratively with approaching deadlines.
But to not get stuck in local maxima you need some time off from feedback loops and tactics. You need time to think, design, experiment, sleep. You need time for creative, strategic thinking. Processes, rules, feedback loops, deliverables etc. are all a hindrance to that.
We need to get back to engineering as an art form, not factory work.
the Agile Industrial Complex realized they can sell that vision to managers, despite it being unachievable.
That promise is so alluring, it’s blinding.
Except you can also measure that we're not hitting any predicted goal times, ever, because our sprint system is incompatible with the nature of our work supporting live systems and simultaneously developing new features. We're regularly taking on work from outside the sprint half an hour after sprint planning, because something exploded and we're the ones who have to fix it.
It's completely impossible, but the vision of predictability has blinded management.
The number of times there's a card on the retro board under "Stop doing" that just says "sprints" on it...
I like Basecamp’s shape up methodology: make bets of efforts that are worth 6 weeks of the team’s time, commit to the best one, timebox it. If it takes longer than 6 weeks, throw it away. This way the risk is limited to six weeks.
Few managers would be willing to stake 6 weeks of a team’s time though.
Well, they think they're minimizing risk, but at best they're just minimizing uncertainty, and the result is predictably low productivity.
- Kanban (no sprints)
- (45 min) Weekly grooming session
- Thrice weekly stand ups (async)
- (1 hour) Retro every two weeks (sometimes we skip it or it becomes a show-n-tell)
- (30 minute) 1:1’s monthly for seniors, every other week for juniors unless requested more frequently
- Optional (1 hr) themed mob sessions / office hours throughout the week. You bring a problem and the group that shows up will work on it with you. Seniors/IC’s are required to hold office hours at least once a week.
- NO OTHER MEETINGS; engineers are asked to block out their lunch/personal time and refuse any non-essential meetings. They have the right to request meetings be rescheduled to appropriate times or moved async.
- NO MEETINGS OF ANY KIND ON FRIDAYS
It could be coming from tests, from CI, from the QA team, from customers, from other engineers in your team, or, failing all that, then yes from management.
But if management is giving feedback that is hard to reconcile with everything else, at this point you can point to CI, the previous tests that were added based on other requirements, feedback you got from customers etc. as justification for your existing actions. It means you're operating with a lot less assumptions because you get data validating what you're doing (and where you should fix things) every step of the way.
The secret lies in the fact that neither giving, nor receiving feedback is free.
Engaging with people, who have different motivations and reasons for being in a job, and stripping away often unhelpful implied titles of rockstar programmer to QA robot, can help everyone to see the big picture and in turn to see how their contributions, their cogs, fit into that picture.
Production-line programming can be left to new automated systems, whilst we can embrace and capitalize on people exercising their intellect for productive, feedback-oriented work.
Making iteration faster let’s you see the results of changes you make faster, that’s the benefit. If you’re iterating faster than you can make meaningful changes then you won’t see any change by definition.
Iteration length is also context dependent. For a multiplayer game I really like being able to see my changes immediately when working on it, I love being able to iterate with other devs on some idea where each iteration is in minutes and we’re chatting about it together but we only test the game itself “as it’s meant to be played” with anyone outside the team once a week. That’s part logistical and partly anything shorter than a week doesn’t usually show enough progress. If there’s some bigger change we’ll also keep our work iterations but pause the larger play tests until it is done.
Short as possible is good advice but you’ve got to look at your own context and make sensible decisions. You can also look at it like following a gradient, if you’re unable to make bigger changes then you’ll just be optimising towards some local maximum.
Micromanagement itself is more about the amount of agency to decide what to do at each iteration.