9 ms·
"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with. "I tried this and
by chomp 8y ago
"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with.
"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.
- ahelwer 8y agoThat's useless because everybody else tunes out. Nobody cares what debugging methods you tried on some project they've never touched. If you need help you can just ask somebody.
- chomp 8y agoI think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped. 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.
- lttlrck 8y agoAre stand up meetings the correct venue for brainstorming?
- chomp 8y agoMaybe not, but if your peer said "hey can someone help me with this task" in a standup, wouldn't you want to help them once the meeting is over?
- kelnos 8y agoReplace that with asking for help in slack or whatever, and you don't need a standup. And you also get help as soon as people's time is available, not the next day.
- maccam94 8y agoNo, but they can spur an interested subset of people to brainstorm after the standup ends.
- bitwize 8y agoNo, those are things you want to take "offline" or "to the parking lot".
- hrktb 8y agoIn some previous team, I realized that some people working on very long tasks just gave bullshit updates. What they explained was interesting, it gave a sense of progress, and they communicated well. 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.
- s73v3r_ 8y ago1. Isn't the standup usually the place you're told to initially ask for that help? 2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?
- Shaanie 8y agoDon't wait until the standup to ask for help if you don't have to. 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.
- fakecigar 8y ago+1 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
- s73v3r_ 8y ago"Don't wait until the standup to ask for help if you don't have to." I didn't mean to imply that, but one of the purposes of stand-up is to give a place for that to happen.
- drunken-serval 8y ago#2 never happened at any job I've had. It was always the entire team and we all had different projects. Sometimes entirely different applications.
- munk-a 8y agoI think your team is too big then. Don't have company wide standups, have a standup per team and possibly role. If you're working on a web stack have a standup where the backend devs talk, one for the DBAs (if that's a thing you have) one for the front-end people... If there's someone in a product manager role they might want to attend all the meetings but likely not. 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.
- jrs235 8y ago>If a clear majority of the audience isn't interested in your status then you're just burning hours. 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.
- scribu 8y ago> what's our goal for today? 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.
- refoundglory 8y agoIf your goal for the sprint is "build widget" then your goal for the day should be "build part 3". You don't change priorities each day, you change how far along you are and where you expect to get to.
- brianmcc 8y agoI agree, what you describe provides an opportunity to solve problems - far from useless! Certainly there's judgement needed in terms of where something becomes too detailed or digresses too far but that comes down to practice and intuition and feedback to get a consensus.
- some_account 8y agoWhat if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing? 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?
- kerbalspacepro 8y ago1. Agile is not personally great for programmers. 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.
- crazypyro 8y agoI would disagree with almost every claim on this list.
- kerbalspacepro 8y agoI don't really have that strong of an attachment to any specific one of these claims. I was just pointing out the logic of the parent comment is very narcissistic (without saying as much). 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.
- nottorp 8y agoAgile is good for managers who are unable to evaluate their programmers otherwise.
- Benjammer 8y agoIt feels like the article is trying to sell a _different paradigm_ and you are arguing why the individual steps won't work under the current paradigm...
- ravenstine 8y ago> "working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with. Don't take people so literally.
- walshemj 8y agoYou can learn coping strategies to get better at it though.
- RussianCow 8y ago> ...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... 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?
- Benjammer 8y agoI have no direct experience, so take this with a grain of salt, but I think this type of thing only really tends to pop up in large multinationals that literally just end up with too many moving parts at certain points to be able to keep every gear spinning at once. The business process dependency tree is just plain old _too complex_ to get 100% utilization of every piece at every point in time. It's more profitable for the business at that scale to have a certain role just "idle" for a period of time rather than fundamentally change business processes to maximize individual resource utilization.
- still_grokking 8y ago> 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. Oh! Just don't give the show people a stage. You know a stage — like daily standups or so…
- deleted 8y ago[deleted]
- jrs235 8y ago>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 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.
- nottorp 8y agoThat reminds me of a job that wanted detailed reports every day. So I ended them with "and I spent the last hour of my work time writing this report". They eventually saw the light. I was one of the two people charged with firing the incompetents.
- still_grokking 8y ago> 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. 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. :-)
- pythonaut_16 8y agoThat was my thought too. 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.
- noddingham 8y agoI agree with you. But I think the problem is that most people don't approach a problem like you explained in your first sentence. It's more, "I'll be googling and reading Stack Overflow for the answer and guessing until I find it". I think it's partially due to a lack of rigor that has crept into coding.