"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.
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.)
The whole agile methodology shouldn't be taken as is. Standups, sprint planning, retro etc all can be ala-carted with modifications depending on what type of team you're in and the people in it. The ideal scenario is that the team is a well-oiled machine, much like a precision, well built watch. No standups or meetings that force context switches and interruptions.
Adapt to the team. Do away with unnecessary processes. Just because standups are done everywhere doesn't mean you have to do it just for the sake of 'following the process'. It also doesn't mean you should do away with it, if you have a team that's new, or if there's a lack of communication or trust in each other. Isn't the point of agile, to be agile in everything that we do, including the agile processes themselves?
We do this on top of a good culture of asking for help and posting regular updates on our internal Sprint tracker, it works quite well.
It's amazing how much of a time saver and efficiency builder that can be. It's equally amazing how many managers prefer time wasting group meetings where people essentially read written reports...
You interrupt people 2-4 hours into their work, which is highly disruptive for those who get the most done in the morning.
Often discussions run on past many peoples' lunch time, which can make people cranky and occasionally leads to tense exchanges which might have been more amicable if people weren't hangry.
You wind up with people melding the work they did during the previous day and the current day. It gets difficult to keep track of what you did between two days' midpoints compared to what you did during a day.
And things get worse as more items are inevitably added to the standup meetings (now we need to check on tests, now we need to add a review of open tickets, now we need to involve people from other teams, etc).
In my experience, pre-lunch scrums result in heavy disruption and a bunch of people who feel like they could be doing other things to much greater effect.
Though that was the full on clean room high level sponsor route, collocated with the customer.
I've been on 11am standups lately and they're not too bad, but it incentivizes me to either come in at 8 or come in at 10-10:30. The latter is what usually happens.
It is true in theory that you can get the same thing from just scanning the project board every day. But people don't actually do it. Furthermore if you're stuck on X, standups are a perfect time for someone who was about to look for a ticket to take one off of you that they are better suited to handling.
Are they perfect? No. There are definitely false positives. But the ratio of real positive to false one is good enough that they provide real value overall.
Sometimes I’d start meetings with, “first, let’s go around the table and report any surprises this week”, and then adjourn the meeting.
The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback.
I find that people are overly optimistic about their chances of getting a task completed in the promised time frame. If something is expected to take five days, I'll hear every day that it's going well, right up to the last day, then all of a sudden it's not going to be done. The more granular the task is, the easier it is to deal with slippage because you get to know about that slippage sooner.
In my experience what happens is one of three things:
(a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of building
(b) You track it as a lot of tasks (~30-50), and whoever is working on it spends half their day fielding questions like "Can I pick up that task for you?" or "why are all the highest priority tasks assigned to the same person?"
(c) You track it as one or a small number of tasks (~2-5), and whoever is working on it has the problem GP mentioned with stand-ups, where they don't have anything granular enough to report and end up looking like an incompetent tool.
I've experienced all 3 and they all suck. I'm not convinced that option (c) isn't the furthest down the right track. Option (a) can be a horror show and probably one of the quickest ways to lose a good dev, option (b) can work but it's dependent on a manager that understands the work and isn't going to lambast the dev for blocking up the backlog with self-assigned tasks. Option (c) just relies on adjusting or removing stand-ups to not focus so heavy on day-to-day progress.
- Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time.
- I'd avoid excessive preplanning. But I'd make tasks to make explicit the general plan and the interdependencies. E.g. create new server API, then refactor client, then remove old server API.
- Don't be too concerned with showing progress in stand-ups. Feeling like you need to do this to justify yourself is a team process smell. Abandon them if they bring no value, e.g. if you have a de facto three people subteam who is coordinating all the time anyway.
EDIT: Also, just because someone is working on a siloed task doesn't mean that nobody else can pick up where they left off. For that to be true you have to assume they document nothing and code like an idiot (which is unfortunately probably pretty common).
Even if I'm not going to be judged out loud in this meeting, I'm going to have to explain myself. I have a problem in front of me that I'm working to solve. Maybe I decided to do some reading about possible ways to solve it. Maybe I decided to learn one of the tools that I'll probably use in the course of solving it. Maybe I'll try a particular approach.
Whatever I decided to do yesterday, I have to decide how to frame it and describe it today. I can practically hear another engineer or manager thinking "why didn't you just X" where X is some simple thing involving less time and thought than what I did. And I don't want to have that conversation with them right now. I am still in the middle of it.
I want to be able to say in a few days, "Here's a solution! It meets the requirements and in a really elegant way if I do say so!" I live for that. I want the freedom and flexibility to get to that point without being probed every day about how I'm getting there. I used to do that, before scrums and standups took over the programming world, and it was great. Having a daily checkin robs me of that latitude.
I'll gladly pick someone's brain if I want their input or feel stuck. But if I want to think outside the box a bit, a daily checkin can feel like a pretty short leash.
This may sound a little funny, but at my work we do daily morning prayer from 9-9:30am (company-wide, 20-25 people). We sing a few songs with guitar, then talk about our weekend or personal life, or whatever. Some days it's more work related than others. Maybe we'll share a little about what we're working on, or bigger updates from managers, but it's definitely not a planning meeting.
It's awesome.
If you're working heads-down for weeks or months without standups, people are still likely to wonder if you're stuck/ineffective/blocked if you're not communicating in more detail than "it's still in progress."
That is, if I am working for weeks or months without making visible progress, but I have successfully delivered the last X things on time, why are you worried about what I look like?
So, yes, people should grow into longer timelines that they can appear to be slacking off. I expect the tasks we've given the newest intern, as an example, to be something that can show daily progress. In large, because it will likely need daily coaching. As you get on the larger projects, though, asking me to break everything down to daily chunks is itself a chore that may add significantly to effort.
Worse, it encourages people to fall for the sunken costs fallacy. If you burned down all of that effort, many folks are hesitant to take any of it back. If I haven't let you know about the small progress I made on the last experiment I did, then I am as likely to abandon the path and try something else if I am confident it will be better.
I'm not worried what the OP looks like, or generally what I look like for that matter, but they were worried what they look like. I just dispute the claim that standups are the root of their anxiety about that.
Yeah, I think a better way to do standups is a couple minutes of social time, and "anybody finish anything? any blockers?" rather than going person-by-person.
Better still for us has been going task-by-task rather than person-by-person. Look at everything which is in progress, get a quick update on it, move on. Five minutes tops, everybody is up-to-date, issues flagged.
Then don't. Give specifics about what you did, what you accomplished or didn't accomplish, and what your next steps are. Provide evidence of forward velocity, or ask for help if you're stuck. The key here is accountability. Don't be "the guy in a room" who doesn't apprise the team of what's going on in his world. That guy is first in line to be fired.
Must I have provided a lengthy, detailed example of what I would say at a standup? I'm the guy who pushed for people to provide more detail at standup. I thought I'd communicated my point and didn't think it a particularly good use of my time or anyone else's to spend more time on that sentence. Now I regret writing that it at all.
If anyone manages to read this, keep in mind that I was not suggesting that a professional update along the lines of "d'uhhh... i did a thing" is particularly valid.
I gotta think that's kinda a common thing to be said and other devs would understand that that happens...
So if you are working on a bug (fixing technical debt) then you are not working on a feature.
Also, working on features is often (but not always) more predictable in time estimation than working on bugs, which can be a completely exploratory task with the only endpoint being "it works now"...
At a past job a very technically strong coworker spent months on a problem and eventually threw the towel and handed it to me. It took me another couple months to find a reasonable solution to it.
Some problems are _really_ hard and no amount of help will get a dev to solve it faster.
Perhaps companies should just pick and choose what parts of Agile methodology suits the situation. I don't really buy the idea that Agile only works if there's an ensemble effect from every workflow aspect made Agile.
Get stuck on something for a few days, and it feels like it's time for a new job.
That would raise immediate, massive, flashing red alarm bells in my teams!
I understand that different environments have different requirements, and different teams have different needs though.
If I was working on a very functional team where we had the employees and resources to work very collaboratively across projects, I'd certainly agree that (groups of) tasks that take that long should raise alarm bells. But most companies, in my experience thusfar, minimally value their developers and only hire X amount of them, so the developers they did hire are naturally forced to take on large projects to the point of taking sole ownership of them.
Disregarding that, I don't see it as unreasonable that tasks shared between multiple people would take weeks to figure out. If I were hiring developers, I wouldn't want them to race to make a bunch of horseshit that's going to fail, but instead they should take their time to figure out the right approach. In conjunction, they should be able and allowed to communicate when long-running tasks aren't going anywhere, without any shame. As long as they document the steps they took along the way, there's no reason that standup needs to play a role; with documentation, a manager should be able to tell if an employee is incompetent or merely trying to do their job right.
I don't think that stand-ups are really a big deal, but if I were running a team, I probably wouldn't use stand-ups in a traditional sense. Rather, I'd keep stand-ups but not make them goal-oriented or strictly related to work in any sense. As I said earlier, I think it's positive for people on a team to interact at least once throughout the day if they are in the office, and a quick and optional stand-up in the morning would be a great way to facilitate this. If someone wants to bring up an issue or asks if another team member knows how to do X thing, then awesome. In fact, I suspect people would be more comfortable in doing so if they aren't wasting time thinking up how to summarize their work for stand-up, and if stand-up was kept casual and didn't devolve into employees reporting to their manager.
In fact, all I like about standups is seeing my team mates once a day. Besides that, there's almost no upside. Literally everyone can read the project board to see what we're up to. If you're really so curious as to what everyone is doing, why not just look at that?