5 ms·
One of the most important things that I've learned over the years is that the Daily Stand-Up is a tool that solves a particular problem. Specifically, if you h
by donw 12y ago
One of the most important things that I've learned over the years is that the Daily Stand-Up is a tool that solves a particular problem.
Specifically, if you have a team that doesn't communicate effectively on a daily basis, then the standup gives you -- the manager -- a place where you can get and keep your developers on the same page.
When everybody already knows what's going on, then the standup loses a lot of its meaning, and should get cut down to "Anybody blocked, or need anything they don't have? Everybody good to go today? Okay, let's make this happen."
But at a lot of companies, it goes the other way, turning into a Kafkaesque version of Show and Tell.
Most people that end up in technical management don't get any serious coaching on leadership or management. This leads to a lot of management-by-bestseller, cargo-cult agile, and the sort of dystopian teams that grind the minds of otherwise talented developers into useless pulp.
It's not that these managers are incompetent or bad-intentioned, just that they never got any solid guidance on how to lead, manage, and grow a team.
What's truly insidious is that the problems don't really start becoming catastrophic for months or years, by which time it's very, very difficult to turn the ship around.
One of the more powerful tools for fighting this sort of problem is the retrospective -- a weekly block of time where the team goes over what works and what doesn't -- but, more often than not, the retro is the first thing that gets cut from the process because "nobody has time."
- JoshTriplett 12y ago> Specifically, if you have a team that doesn't communicate effectively on a daily basis, then the standup gives you -- the manager -- a place where you can get and keep your developers on the same page. The standup should not include the manager as a participant; that's broken. The standup is supposed to be for coordination among the team, not status reporting to the manager.
- manigandham 12y agoIsn't the manager part of the team? Most of the time, the manager is partly responsible for solving the "blocked" and "things needed to do this task" issues that come up so it's better to have them there then not. If the whole point of a stand-up is to have all the team members forced into a quick acknowledgement, leaving someone out doesn't seem to help.
- Cthulhu_ 12y agoMaybe for single-team scrum projects, but if you have one manager per team you've got way too much management.
- foz 12y agoTechnical teams often have a team lead, who can be the line manager for the developers. This person is part of the team, and can help identify problems and fix them. I think this works better than managers who are not involved in the daily work of developers.
- yareally 12y agoI'm the team lead for my team and that's more or less what I do. A lot of the developers on my team are juniors and haven't developed the sense of knowing when there has to be an obviously easier way to do something and ask someone or search for it. Standup helps me to see who's stuck or where I can help them with an issue that could be done more efficiently from my own trial/error and experience. Overall, I do as much coding/development as anyone else on the team. However, I also identify problems that others on team may not see until they become serious. I also look for ways to make the team more efficient through automation of the more tedious/repetitive aspects of the development process and implement a solution when I have downtime. For example, we have a lot of network/hardware integrations we support and each one requires reconfiguring a database and reloading a couple services. This reconfiguring was being done manually much of the time through the web interface so I tracked down the rows being changed in the db by doing db diffs on each configuration and scripting out the changes that might be different on each developer's machine. Instead of manual config, developers just put a few custom constants in a json file, run the script and select the configuration they want to load from a script. That then updates the test db and they can be running/debugging their code in less than a minute instead of up to 10-15 at times (plus time lost from losing focus/train of thought). I know my example is nothing amazing really, but with some developers having to test a couple configurations a day, that time adds up without realizing it. The db schema rarely changes nowadays (maybe once a major version), but if it does, I just have to add a column perhaps at the most to the script and have them run it again after they update their build.
- vpeters25 12y agoI think it's actually the opposite: everybody is invited to the daily standup, even the janitor if she/he so pleases... but only developers can talk. I sell the daily standup to the developers as a tradeoff: we do a quick daily meeting in exchange for keeping stakeholders off your backs the rest of the day/iteration. EDIT: phrasing
- JoshTriplett 12y ago> I think it's actually the opposite: everybody is invited to the daily standup, even the janitor if she/he so pleases... but only developers can talk. You're right; a better phrasing would be that the manager is not an active participant in the meeting. It's a developer coordination meeting, not a status reporting meeting. So the manager is welcome to listen in, but they're not supposed to be managing during that meeting, and in particular they should not be asking questions, because that'll very quickly turn the standup into a daily status report instead.
- FeepingCreature 12y agoI just had a weird idea. Absolutely no experience, so this may be stupid. Has anybody tried to replace this with a "daily shared morning tea/coffee"? Create a collegial atmosphere that's intrinsically unsuited to active management; there's no real need to keep people ontopic anyways because they'll naturally talk about work. Plus drinks may keep people occupied enough that only one person would naturally talk. [edit] Oh, is that what the watercooler does!
- vpeters25 12y agoI actually like to run standups as "all business": everybody says their piece and goes back to work as quickly as possible. One of the main goals of Agile processes is to remove overhead from the developer so they can focus on adding value to the stakeholder. Anybody who starts goofing around the standup is disrespecting and wasting the team's time. Now, your idea might be worth a try. As I said in another post: the team runs itself and might decide to try something like you propose... and keep doing it if it works for them.
- mattschmulen 12y agoI'm with you brother , don't give into obsessive insecurity. Retrospect for the win , have faith . an hourly pulse does not help you predict a heart attack any better than a weekly sampling
- warkid 12y ago"It's not that these managers are incompetent or bad-intentioned" +1. A "manager" can't replace a "team". And having a "team" is one of the key aspects of being agile(this is what "peope and interactions" is about).
- warkid 12y agoI've used word "replace" in another comment about pair-programming. It feels now that it's a trend in "cargo-cult-agile" to somehow inverse agile manifesto principles. E.g. replace understanding of how team should work with a formal sertified scrum process - "you do iterations, standups and stuff - you fine!" Burn-down carts and sheer numbers of closed tasks disguise real state of the software being developed(just create more tasks and then split them to create volume).
- nickbauman 12y agoThe part about the stand up that's "what did you do yesterday? what will you do today?" is the part that is the anti-pattern. In a well functioning team, the only thing that needs to be communicated is "Heads up: you need to know this now..." That's the part of the stand up that really matters. Many of my best stand ups go like Mary: "Nothing to report." Jon: "Nothing to report." Dyneshwari: "Nothing to report." Shruthi: "Nothing to report." Su: "Nothing to report." Grant: "Oh, we moved all the test databases. You need to get the latest base data in your environment or you won't be able to work." Joe: "Nothing to report." It's over in 1 minute.
- a3n 12y agoWhat happens to Fred, who had an appointment and wasn't at the standup? I suppose in this example he'd notice that he isn't able to work, and ask around, but ...
- lmm 12y agoIt's imperfect, but IME a standup is more reliable and usable than any alternative I've seen tried. Emails get lost in the noise (that people get too much email at companies is its own problem). A Slack highlight can be more of an interruption, and non-technical people find it hard to use / won't always be responsive there.
- a3n 12y agowhy not an internal blog or wiki? Or a compromise, someone transcribes essentials from the standup to the blog or wiki.
- lmm 12y agoInternal wiki hits the same problem as email (although partly because companies always seem to choose terrible wiki implementations (confluence)). Too much information goes on there, terribly organized, and no-one ends up being able to find anything. Mostly these kind of things are immediate announcements that need to be acted on once and never again, so a semi-permanent store isn't appropriate; also the whole point was that everyone needs to be notified, but people can't watch every wiki change. Blog I haven't seen tried, but I imagine it would hit the same problems; either you notify everyone and have the same problems as slack, or you don't and have a big risk of someone missing an update.
- frownie 12y ago>> Specifically, if you have a team that doesn't communicate effectively on a daily basis, I concur. My people don't communicate very well and have no real team spirit. The stand up meeting helps to alleaviate that. Of course, people who "don't communicate" and "have no real team spirit" are not fit for Agile and stuff, but that's another story :-) In my case, Agile, having frequent deadlines and frequent stand up meeting, helps me a lot to maintain a soft pressure on people. I don't like that (I'd prefer a team of super motivated people), but that's the best I can do. Having a more formal method like RUP wouldn't help because the analysis/coding cycles are too long. Having a kanban could help a bit, as Agile with such a team feels a bit artificial.
- ramblerman 12y agoI can only go by the 4 sentences you typed above. But you don't come off as an inspiring person to work for. "My people" are all terrible and need "soft pressure" to succeed....