If a clear majority of the audience isn't interested in your status then you're just burning hours.
Also a standup with 40 or 50 people is just plain silly. I worked in gaming a few years ago and our standup was a full game team, the artists, designers, QA, server-devs, client-devs and our stats guy all spoke. It was a bit interesting to see what artists were doing but totally unnecessary for me to hear anything anyone said except the two other people I worked with, and we communicated well outside of the standup anyways.
From my understanding stand ups are not supposed to be status reports. They tend to turn into them though as it seems the most common format is 1) what did you work on yesterday, 2) what are you working on today, 3) what's blocking you?
I prefer daily stand ups (near the onset of the day) for small teams to be 1) what's our goal for today? 2) what might block us or slow us down? 3) how are we going to tackle our goal?
When stand ups start feeling like justifying your existence then morale drops, [looking] busy work increases, and too much time is spent on CYA. Focus on solving problems not explaining them.
The same as it was yesterday or whenever the last planning session happened.
Like TFA said, the team, as a whole, shouldn’t be changing priorities like socks.
Tried that once as a team. Then it became a derogatory joke word, haven't sprinted since. Well only in real life when playing tag with my kids.
Estimating, delivering on time, working together, can be hard. Someone deciding to rename it with a new label, doesn't usually solve the problem, though now everyone has a new label to make fun of.
If your standup can be replaced with everyone posting on a slack channel, then it's just a status update as there's no discussion and alignment happening, which are the valuable parts.
Most teams should experiment with their process more.
Blockers - hopefully blockers are identified and communicated right away vs waiting for standups.
How to get stuff done - less unnecessary meetings and processes. Async communication.
I thought that was the kind of situation he meant, where people zone out because they don't work on that project, but who knows.
You shouldn't assume too much about the environment other people work in.
This would be better solved by hosting specific IRC channels for those roles and having occasional role-specific meets/lunches to introduce new people.
Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an absolute delight and completely useful.
I will qualify all of my opinions with the fact that the best teams I've worked with implement Kanban, so there is no sprint planning. We just pull off backlog and work with weekly standups. There's way way less overhead, with some tradeoffs.
I also definitely think that certain team cultures are completely incompatible with standups, to the point that you receive negative benefit from implementing them. If you have a lot of people who are of the type "my responsibility ends where my story points end", I am pretty sure you will end up have a bad time doing standups.
Too well perhaps, their small talk was on super minor or even unrelated stuff that they saw the previous day.
They were doing mainly exploratory work, and it made no sense to bring on board other people before they settled on a direction themselves.
I think ultimately a one size fits them all approach only “works” when the people on the fringe also play the game and bullshit (in a good light) their way around.
I likely will never understand the great minds behind management.
However, if only some people speak that can create divisions in the team, or make it look like the speakers are the leading members when that may or may not be true. So to prevent that dynamic everyone says something, and people can help the team function better by coming up with a nifty one minute oration.
Ultimately making software is a human endeavor. Sometimes a little small talk prevents the humans from feeling bad and not making software. Sometimes it has the opposite effect.
The best managers figure out which case is true at a specific time and place and adapt. Good managers just have to pick what risks to take and live with the outcome.
2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?
I'm also confused why OP is having standup eith people who havent even heard of the project he's working on. Doesn't sound like he's working on the same product as the other developers.
The standup should be the place of last resort for bringing up barriers impeding a task. The more resourceful you can be at solving a problem/brainstorming outside of the standup the better ime
I didn't mean to imply that, but one of the purposes of stand-up is to give a place for that to happen.
I'm glad I haven't lived through that hell.
They eventually saw the light. I was one of the two people charged with firing the incompetents.
Oh! Just don't give the show people a stage.
You know a stage — like daily standups or so…
I find this concept very strange. Maybe it's just me, but aside from one time where the agency I worked for briefly had no ongoing client work, I don't think I've ever felt like there was no work for me to do. At all my past jobs we have always had a large list of small, low-priority tickets that people can pull from if they are blocked on their larger tasks. Is this not the case at some companies?
Don't take people so literally.
Some people indeed need spoon feeding. That above statement only strengthens my view.
Or how do we interpret "unnecessary mental load" out of the mouth of someone likely in management when it comes to simply reading a task board?
Sometimes I really wonder what most of the management is good for… Really.
Running around, having a lot of meetings, but nevertheless not knowing what is happening all around them, so they have to ask every day anew…
But now I understand: It's only a unnecessary (too height?)^^ mental load to read the task board. :-)
If it's an unnecessary mental load (for developers or managers) to find out about the tasks currently being worked on and what they are, then the problem is with your work/task tracking system, not with your developers.
You need a strong manager or leader willing and able to reign individuals in. This person needs to open the discussion space to others and prevent the loudest (and it sure seems often like the most opinionated) from interrupting.
The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now.
It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.
Let's just stop pretending it's good for the programmers, alright?
Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startups, or just for anyone going after something that's never been done, you need to take a risk, and that risk includes your programmers as well.
What's more, there's a small but important difference between being told to go to a meeting and converse with other employees, or CEOs, or clients to get some external validation on your work, and choosing to seek out those people of your own free will. I agree that no programmer can silo themselves off and "do work", but that doesn't mean we have to infantilize them and spoonfeed them their feedback.
A fisherman knows how to catch fish, so why are you telling him what lure to use and how to cast his line rather than just letting natural competition takes it's course and allowing him to become jealous of the better fisherman and having him improve. "Didn't catch a fish today" "well you should've used the red lures like Bob does". Do you want a better fisherman? or do you want the same fisherman?
The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution.
On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.
The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science.
The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging.
I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do.
Personally, I've been on both sides of this pattern and I would rather still have standups.
As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.
Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock.
As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help.
Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.
>What if I just want to focus on building, not explaining and sharing?
>it makes them share if they are thinking incorrectly about something
>it makes them easily replaceable
I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you aren't able to explain what you're doing and share your thought process. Writing buggy code and refusing to work with your team is a primo way to get canned. Owning the fact that there's time constraints and imperfect code and minimizing the risks taken and assumptions made by understanding the architecture is valuable.
Stand ups might not be the way to do it, but if even the prospect of sharing your thought process and explaining what you did strikes you as being 'micro managed', well.......
And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."
I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective.
Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn.
Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented.
I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.
I've often been the guy who comes in to help untangle a messy code base, and an entrenched "just let me build shit" attitude appears to be a chief predictor of unextensible and inflexible design. Even when not in a managerial role, I don't like to see people working in silos because experience has taught me that I'm gonna have to deal - as a fellow dev - with repercussions of poor design sooner or later.
> It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.
That's absolutely the point of a team. Contrary to popular belief, a team is not a meritocracy[1], it's a mediocracy. The beautiful thing about a mediocracy is that it means that you can take vacation or quit and someone else can pick up your work. We have a pretty good gig that we can just chew through tickets, imbibing coffee and excreting code and poo.
Not everyone has that luxury. For many actors, their face needs to be in every episode, so they sign a contract with stiff penalties if they quit.
[1]: Engineering is meritocratic in the larger market; if you are better or worse than your team's medium, you find a better team where the medium is closer to your skill level.
2. Agile is good for managers.
3. Managers run the business and make sure it exists.
4. Programmers need the business in order to have a job.
5. Agile is therefore good for the business,
6. And therefore Agile is good for Programmers, though not personally.
The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.
5. Agile may or may not be good for Programmers.
6. Agile may or may not be good for the business.
Agile is not actually for managers, in that productivity suffers a lot, less software with real value is produced.
But software productivity is notoriously hard to measure, so it is ignored.
Explaining and sharing are important. The difference between micromanagement and management is, IMO, somewhere between daily and quarterly.
(Most of my coworkers thought he was being sincere in his flattery rather than being ironic. For all I know they are still being 'too important' to work on new subsystems.)
"I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Stand ups are about communication with your peers. Having to hunt down tasks you're working on and reading through each task can create an unnecessary mental load that can be solved with a single 1 minute "ESPN sportscenter edition" summary of your current issues.
However, blockers do create a sense of ineffectiveness. Especially on small workload teams where task swarming doesn't net too much benefit. "Hey I am still waiting on $vendor to configure their service" or "Still waiting on netops to tag $port for vlan blah" or "Procurement put in a PO for $hardware, still waiting on it", there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further, to which I have to say, pair program until your blockers dissipate. We do this at my current job, and it really creates tangible benefit.
As for TFA's bulletpoints on why sprints can be bad, most of their arguments are bunk except for this one:
> 4. Extroverts thrive at stand-ups, planning, and retros.
Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue, but I do think it can be a problem for a lot of businesses and teams.