A good team just fixes things with no need for a meeting right? Nyes, sort of.
Fellow reader G asks:
re Your comments on retros: what do you think about Allen Holub's views in his "death of agile" talk? He says a good team just fixes things that are broken, without the need for having a regular meeting. I tend to agree!
This was in response to my Onboarding to a New Team article where I mentioned that regular retrospectives are the best place to introduce process change. And that if you don't have those yet, you should start.
Death of Agile
First, I love how Allen Holub starts his talk and agree 100%.
Agile is the best way we know of to produce software. When I talk about the death of agile, I'm talking about the death of real agility and the replacement of real agility with a fake agility that is suitable for corporations but doesn't work in the real world.
YES! This guy gets it.
When you see me talking about agile, I'm always talking about "small a agile". The one that empowers software engineers to do their thing – focus on user value – and tells management to get out of the damn way.
Agile isn't something that you do
Lots of people think that agile is something that you do. You pick a process off the shelf, start doing your standups and sprints and retros and jira boards and point estimates and voila you're doing agile.
But agile isn't something that you do, agile is something that you are.
Look at the original agile manifesto. It's fantastic.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
When you do these things, the rituals come naturally. They follow out of your team's agility.
Yes over time we've found common patterns that agile teams fall into. When working together, it's nice to quickly sync in the morning. You can't plan more than 2 weeks ahead, if you're not sure how things evolve. You need a scheduled time to talk with stakeholders because they're busy too. ...
But agility comes first. Not the rituals.
As Allen says in his talk: The organization needs to be agile. You can't have an agile team inside an otherwise in-agile company.
Why retros are good
A retro is your team's regularly scheduled time to talk about process. What worked, what didn't, what do we want to change.
It forces the conversation.
That doesn't mean you have to wait until retro to make a change. If something's bugging you, change it. If the way a coworker writes slack messages doesn't work for you, tell them. If you're annoyed by large PRs, start making small ones and lead by example.
You don't need a whole big conversation for every little thing that's wrong. The best time to fix things is now.
The next best time is when you're all "in a room" together holding sacred time reserved for "How can we work together even better?". There is no urgent work to distract you, no last-minute meeting to pull you out, no quick thing to finish.
A retro is like date night with your spouse. You put the phones away, you stash the kids somewhere safe, and you focus on you.
It's okay to end retro with "We're perfect, nothing could be improved". But then I think you're just not complaining enough. There's always something that could be better 😉
Cheers,
~Swizec
PS: I fully support regular retros with your spouse, even yourself. It's easy to miss all the little things that grind your gears when you never stop and think back
Continue reading about Why you need a regular retro
Semantically similar articles hand-picked by GPT-4
- Nobody is coming to save you
- Coordinating at the end is too late
- Onboarding to a new team
- What to do when bugs are whack-a-mole
- The art of the cowboy merge 🤠
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️