A team where the Engineering Lead(or any kind of manager) thinks that you don't need retros because there are no problems is exactly the kind of team that needs retros.
This is a situation that really depends on the team. If your team isn't surfacing issues, then either you're creating an environment where people don't feel comfortable surfacing issues, or your team is mostly just not the type that is proactive about it.
If it's the latter, then "priming the pump" is a useful exercise, and a regular retrospective makes tons of sense.
That's also generally true of processes: every team has its quirks, and you fit the processes to the team's quirks.
My experience is that most retros result in a list of things that should get addressed but never get addressed. Especially because they must be addressed by larger organizational changes once the low hanging fruit has been addressed, In teams where we actually addressed these issues we ran out of things to say in the retro after a few times.
Things being recognised and never/rarely acted on is better than them going unrecognised entirely. At least in the former scenario, there's a shared awareness of the problem.
Meh. A team with a leader/manager like that isn't going to get much value out of retros because either the leader/manager isn't going to listen to what's being said, or everyone won't feel safe enough to be able to say what needs to be said.
It's hard for me to dislike this, because I also find standups and sprint planning meetings to be painful and somewhat less than useful for myself.
On the other hand, when you are with a new team, or a team with a few people that need mentoring, or going in a new direction, I find that it's important to force people to coordinate, because many times people will just run off in random directions you don't want them to. You really have to have the best people, and trust their instincts if you follow what the article suggests. Any weak players on your team will just be lost and potentially set you back (or at best, just waste their time).
Exactly. This could work well in teams where the engineers are all competent and really just need the PM to stay out of their way.
In weak teams, this could easily see an end-of-quarter with unmet deliverables and other management messes. A lot of people would take advantage of the hands-off approach as much as they could.
Either way, Agile is ridiculous so I agree with the author about that.
Bull-fucking-shit; you know why Spotify's engineering team does well? Stripe's? Netflix's? Because they have money, they have money so they can buy the best engineers. You ever see a small business development team compete on their level that isn't a bespoke design firm?
In my world, my team isn't an olympic-performing high-end software engineering pack. They don't lead in particular subfields in FOSS in their spare time. So you know what? They need fucking plans.
This article is a glorified, "Well if you're good you don't need process," piece.
I didn't see it that way. The article argues for a very clear and curated Backlog of tasks. If engineers can't define tasks well and PM lacks understanding to structure backlog well then no amount of Engineering Olympians will help.
This is pretty condescending to your team. They might not be rockstar developers, but they are adults and can probably manage their time themselves. You don't need to be the best programmer to manage your time, you just need some common sense. If I were working somewhere where the manager thought I couldn't plan my own schedule, I'd look elsewhere.
> you know why Spotify's engineering team does well?
> Stripe's? Netflix's? Because they have money
No. Some places have too much money, others enough and then there are those that may have to shut down in half a year. Seen them all, and "engineering aptitude" is completely independent of that.
And Uber has lots of money, but their product is still a shit-show, although, granted that their payments platform has excellent uptime and works very smoothly given the n-to-n model of the system.
It sounds like the product your business is developing is scoped too large for the revenue or market share it can realistically capture. Scope according to money available, then your product, and your team, will be happy for it. The business will flourish too, and maybe you'll feel less stress.
Money gets you to a certain point, and does provide a cushion against certain errors. But if you simply spend money on the best engineers without a plan and shared purpose, they will leave.
I upvoted because I partly agree - if you're good you don't need these various methodologies. However, I'm curious - do you think these processes can actually convert a bad team into an ok one?
I'd really like to hear thoughts on how this applies to remote teams. I find that async standups via slack are pretty damn helpful for keeping everyone appraised of what is going on across 5 timezones.
Process and communication are kind of key, aren't they?
Async standups do well only if the engineers have the discipline to actually go through them. My past experiences have shown a couple devs paid attention to the standups to look for issues and everyone else just typed their own up without looking at what other people wrote.
This is what everyone does in person too. The people that go last tune out because they're preoccupied about what they'll say and the people that go first stop listening because the value of the information tends to be very low.
I don't think slack standups are a useful way to communicate this. I'd rather have it in the form of trello or pivotal tracker, for example, because those have audit logs and commentary. By all means, have people update those things at the beginning or ending of the day on a routine basis, but doing it in chat is just too ephemeral for me.
I think it's often useful to ping people if you know you're going to need their help, for example, but that's not precisely a standup. It's just scheduling and communication.
Async standups are great even for on-site teams. First, people only spend half a minute to post it; manager needs half a minute to read it to know whats going on. After it is posted, everyone have something to refer to before the weekly meeting, which does not have to be long if it is well prepared. The set up keeps the communications efficient and consistent.
As for the original post, the outstanding team does not need the manager, so far. It will need one, after the writer deteriorate the culture and communication channels that have been established before him with own "trust" and f-words.
While I do agree with the sentiment of reducing meetings and time spent planning, I don't believe that removing all scheduled communication and planning is a good answer. This approach is especially problematic for teams that are working more directly on rapidly changing business concerns. Communication, planning and analysis are quite important for teams with members who need regular guidance or teams with lots of distinct roles.
ah, gratuitous obscenity. the sign of someone that really knows what they're doing, from whom we should take advice.
it's still worth reading, not for what it says but what is between the lines. "how not to do sprints". admittedly this isn't (must not be, i guess) common, but at my current $JOB we do dedicate entire sprints to tech debt. remote people phone into our sprints and are well included. it actually HELPS remote contact as there is at minimum a daily interaction with the entire team. (@tapvt had a similar comment.) his comments about changing the course on a daily basis is another example of likely abuse of sprints.
I'm having a hard time agreeing with a lot of the points being made (I mostly skimmed but also read some parts).
The conclusion is relatively sound though: the default agile approach (sprints, standups, planning, grooming, retro) is only a base to start working on a software development project. The team members should optimize it or even throw it out if it works for them.
- Daily standups are a tool for coordinating teams.
- Weekly planning is a tool for iteratively communicating about the progress being done, steering the team and discussing priorities
- Retrospectives are a tool as well; a quorum regarding what goes well and what should be improved.
In a well functioning team, you will always need coordination/communication, progress visibility, continuous improvements, etc.
I picked 2 red flags in how this junior product manager approaches their work:
- the team did not discuss estimations
- he told his boss the team will deliver after 3 months
Basically he just "winged it" for his first project, picked a waterfall approach, and made it. Congrats! That tells me he either has a kick ass team (thank them) or the deliverable was easily achievable (thank the boss), or more likely a bit of both.
Let's take a few of the points being made throughout the post:
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
This is spot on. Using a tool to keep in sync is only useful if the members keep it up to date. If the tool is not up to date, the team either has a tool problem or a people problem.
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
I strongly disagree there. Nothing, in each team member speaking daily, for less than 2 minutes, about what they are working on, encourages change of plans.
When the author mentions standups routinely lasting 30+ minutes... well yeah either fix it the soft way (time limit + a judge making sure everybody stays on point) or the hard way (just stop doing standups & send updates through a different channel).
What I've seen is that there are usually 2 team members that come with the 'authority' to make for a great standup: the product owner (in this case our author) or the tech lead (well, seems it's the author again, as a technical. prod. owner?).
> Standup forces every team member to be productive at a set place and a set time
Yes it can be a problem. That could possibly be reason #1 to get rid of standups. We're lucky in our remote team that everybody is happy starting the day at 9am as standups mid or end of day make not much sense.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
Again, it sounds like standups are being used for the wrong thing. The standup is at 90% a 'passive' communication tool. Listen to the others carefully. Wait for the standup to be finished and FREE PEOPLE FROM THE MEETING to catch up with whomever you want on whichever subject you want.
> Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
Absolutely, problems that can and should be addressed on the spot MUST be addressed on the spot or taken ownership of by a lead and then addressed timely.
However that approach does not catch everything. Retrospectives are an excellent way to make sure people can flag issues. It is natural that, in the week, someone will be too busy to immediately flag an issue, but make a note of what could be improved. A regular open quorum dedicated to these things helps share these details.
There are 2 critical elements to successful retrospectives:
I've been managing engineering teams for a few jobs now, but I think this article suffers from some logical fallacies.
"You don't need stand-ups"
I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.
I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.
But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.
The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.
I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.
This sounds to me like a team that went through the agile rituals until everyone was familiar with the benefits and methodologies and got rid of the formal structure once that happened. That's fine. But having structure in place around these things is helpful to newcomers, especially when the entire larger organization is trying to transition from a waterfall process or no process at all.
The list of rituals the author got rid of shows that the team has already learned the more abstract values and benefits and is doing them real-time instead of scheduling them as standalone meetings and sessions. It doesn't mean these things have no value; it means the team is a well-oiled machine.
Except standups. Standups are, have always been, and always will be a waste of time.
One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing the same thing I'd been doing for the last several days, like a broken record. I don't want to have to say "Yup, still workin' on those bugs" every morning. When shit's fixed or I've completed a feature, I'll let you know.
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?
Besides that, I hate that they took me out of rhytm of work. If a standup is at 10am, and I arrive at 9am to do dev work, there is very little I can do before being interrupted - I need at least 2-4h of interrupted time to do some good work.
In my team, we have it early in the morning, so we can overlap with India. Folks in US have rest of their day for work, whereas folks in India do the standup at the end of the day just before going home.
It works very poorly in practice, in my experience.
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.
I think this is the correct way to do standups for most teams. It's asynchronous and non-intrusive, and there generally isn't any benefit from doing the standup in person anyway (aside from seeing people's faces if your team is remote).
For technical or non-technical teams, this is usually all that's needed. If there are any questions, they can be addressed below in a reply thread or via a call or face-to-face.
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...
That's why you should do them at the end of the day as we did of my first very successful Agile project - presented at the IIIE I believe after we finished.
Though that was the full on clean room high level sponsor route, collocated with the customer.
I did that (4pm standups) for a while on a team that was just me and another guy plus our team's dev manager, qe manager, and product manager. All the managers were in HQ, my teammate and I were in separate remote offices, so it was done over Hangouts. We loved it being late and got a lot done for just two of us over the few months, but the managers didn't like it (very few times they'd all show up, and dev manager always showed up while on a bart train) and killed it (back to 10am meetings) a few weeks before the team dissolved.
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.
>>In fact, all I like about standups is seeing my team mates once a day.
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.
I've run my team's stand-ups for several years now. I find without going person by person there is less communication. I still restrict each person's comments to blockers and their agenda for the time until the next standup (not daily). It's not uncommon for "no blockers, tickets X, Y, Z for next day or two" to be it for a report. It's not common but occasionally this will remind someone else of a blocker they have which they can chime in with during their update or else at the end if they've already gone.
Agreed with this. I'm actually curious what level of engineers Jason is leading. If it's a group of senior engineers, I'd imagine everyone already knows what's expected of them, but a group of junior engineers might be a different story.
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.
For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning.
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.
Maybe other teams work radically differently, but everywhere I worked it was inevitable that team members would occasionally get "meaty" projects to work on where they would take primary ownership. Under the repetitiousness and time constraint of stand-ups, it still outwardly appear that the smaller tasks broken out of a large project can all sound the same to others on the team who are only mildly interested in the details of other people's tasks.
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.
"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.
That'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.
I 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.
Replace 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.
In 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.
It's a trade off. Some of the communication is very valuable, and needs to happen for coordination, knowledge sharing, etc. The potential harm of that communication not happening is great, the risk of having a meeting go 15 minutes longer is worth trying to avoid (hence the article) but much smaller.
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.
Don'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.
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
That sounds like you were all on different teams, in the sense being used here, and probably shouldn't have all been in the same standup together apart from maybe a once-a-week catchup.
A friend worked in a startup where 20-30 people of the tech dept. had a hour long standup. QA, sysadmins, developers - all had their 2 minutes to essentially do a daily status update.
But you are in the same team in all the other senses, mostly that these are the people you work with in the long term. Some projects you do alone, some with Bob, others with almost everyone, but the team members want to feel like a team and have an idea of what everyone's working on.
I 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.
>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.
If 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.
The term "Sprint" makes me cringe, it's meaningless in my experience. It doesn't effectively identify goals or deadlines. It's a stupid techie/hipster term that no one apparently pays attention to.
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 you're doing kanban and work in an environment where product direction changes quickly, then definitely this.
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.
The standup should be with the people on the current sprint. Alignment should have happened in earlier planning stages. "Discussion" is (should be) highly structured in a daily standup and any discussion that is like a dialog should be placed in the parking lot until the meeting ends, when only those interested in that discussion need to attend.
>
I 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.
This would be better solved by hosting specific IRC channels for those roles and having occasional role-specific meets/lunches to introduce new people.
My team is about 8 people, but we work on about 15 projects, some with about 3 FTE, some take up a few hours per week of one person on average. It happens that someone works on a project on his own for months at a time. There is some shared tech between them, but also a lot of specific stuff.
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.
I 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.
What 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?
I 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.
Unfortunately, you have been taught and are executing Agile in the completely wrong fashion. My first guess would be, you are actually working in Waterfall, but your managers have labeled it Agile and cherry-picked the parts they liked.
Agile has a remarkable resemblance to both communism and faith healing: Every time I say it doesn't work, a true believer replies and says I wasn't doing it right or I didn't believe in it enough.
A boss used to say to us, you haven't proven you know how to do it until you've done it twice. This is, as I recall, also the guy who would pigeonhole people who built things that they couldn't hand off to others. He fed us some bullshit line about being 'too important' to work on the new cool stuff. It was a hard lesson but I learned pretty quick to put extra time in to make my code obvious to others instead of just me. Boost your truck number if you ever want new scenery.
(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'm not sure how much that micro-managing aspect is peculiar to agile and how much is just inherent to working on a team.
> 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.
Unfortunately, we do not live in Utopia. In reality, politics, competition and self-interest play huge role in the workplace. In some companies, admitting a mistake or showing vulnerability in front of the wrong crowd can be very damaging for your career there.
That sounds like hell. The sense of ownership, achievement, and subject matter expertise when driving projects from ideation to completion is everything I like about my job. Working on scattershot, atomized tickets from an assembly line would be awful.
>What 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?
>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.......
This mentality is the root of the problem (from the dev perspective). The GP commenter is saying "these processes don't help me to feel that I've done my job better."
And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."
Do you care how useful the thing you're building is for the people you're building it for? How well it fits in with what other people on the team are building? If any of your teammates have ideas that could be helpful, or have learned things that might be of interest to you?
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.
A manager usually has several distinct projects in the air, with ICs working on them in groups of 1-3. Someone's work isn't relevant to you just because you report to the same manager. The "team" for standup, sprint planing, etc. is really several teams, each tuning out while the others speak. And because small groups can communicate fine informally, the relevant-seeming part of the team-level ritual is always a rehash of what the project staff already know.
Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view.
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?
It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.
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.
Developers come in all shapes and sizes. Some barely use Slack and are laconic on standups.
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.
If the team is truly a team, that kind of goal-oriented facilitation really isn't necessary. While it's good to have some sort of institutions within a team, good quality teams tend to be self-organizing. If employers focused more on creating quality teams, they wouldn't need tools like Scrum to mitigate problems that might not even exist (the fact of which can easily be swept under the rug by rigid adherence to such systems).
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.
There's still code review right? And if you're off building something more involved, then hopefully that code review is happening on a weekly basis with at least 2 people reviewing it so that there's input and ideas and corrections happening. It's brutal to see someone waste time on building out unnecessary parts, etc. Plus it's also useful to reduce bus factor, have other people in the loop to pick up the work if necessary.
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.
ah the black hole programming movement! We've been there with "waterfall", which was a disaster. Not explaining and sharing is counter to working on a team. If you are a one man army, and no one knows what your code does, or if it can be compiled or deployed without errors, then that is bad for your company.
It 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...
> ...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?
I 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.
> 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.
>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.
> 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. :-)
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.
I 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.
The one thing that I like about standups is that they make real blockage or ineffectiveness more visible.
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.
> there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning.
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.
A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that?
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.
I struggle to think of an example where I'd ever let somebody go off and work on something for months. I can't think of how they would be successful, let alone take on the risk that they quit or get hit by a bus and nobody can continue the work.
It really depends on what kind of software you're building. A large new CRUD feature (which is what most of us are building 95% of the time) can easily be split among many people. But a complex data visualisation, or a novel algorithm, can easily take a month or two and isn't easily split amongst the team, even if you have multiple members with the expertise to implement it.
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).
This type of work is highly atypical. All the scrum ceremonies were designed around fast feedback, if you can't fit it into the work you do then using anything agile-related is not going to work.
- 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.
Oh for sure, I'm not saying not to involve other people, just that the actual implementation for some things is most efficient if it falls to one person.
I have other issues with standups, but if your concern is "I don't look productive and I don't want to talk about what I'm doing" not having standups isn't going to make you look more productive.
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."
I think the desire is more to have goals and work towards those. If you don't have daily goals, then having a daily standup is going to be pointless.
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.
> 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?
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.
I think it is fair to think you will be measured with the same general yardsticks that your peers are measured by. So, if you are in a standup where others are giving daily task reports, it is natural to expect you should. And that if you are not, it is natural to feel something is amiss.
Whether standups are useless or not depends on the dynamics of the team. With the team I'm currently working in there are no standups, all communication is async and everyone knows what everyone else is working on. If there's a problem, holler in chat, or discuss IRL. There's also the project board where anyone can just hop in to see progress. There is a trust in each other in my team, which is not something I can say for other teams I've been with.
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?
I first read your comment as the inevitable "that's not true agile" response. Haha
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.
"still workin' on those bugs" is really pretty useless. I'm not suggesting you're not a disciplined person but at some point, debugging something for days on end is a sign you may need some help, a fresh set of eyes, or come up for air and re-group. Same goes for feature development. If a single user story representing a whole feature (or part of a larger one) goes on and on and on, that's either a sign you perhaps rabbit-holed it too deeply, need some help from another team member, or need to raise a flag and split the story into another piece, possibly even one someone else can rally around to help close it.
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.
As a n00b just getting into software development this might be a dumb question but does saying "Yup, still workin' on those bugs" really create a sense of blockage or such?
I gotta think that's kinda a common thing to be said and other devs would understand that that happens...
The problem is that product managers and management in general want features and don't care about technical debt.
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"...
If working on the same ones, then after a few days, yes. By then you should have explored some debugging techniques, options for solution, etc., and either can't figure out how to replicate or debug it or have found a tricky bug and 1-3 ideas for a solution, but all the potential solutions seem bad. That's when you can say you're blocked, ask the team for ideas on how else to replicate/debug, or try to get consensus for the least-worst hacky fix that you've come up with, or any other ideas based on what you've found. We all spin our wheels or get stuck sometimes, so of course we understand, and that's exactly what it's for. But you have to give that context and say where you're stuck.
> I don't want to have to say "Yup, still workin' on those bugs" every morning.
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.
I find it interesting how literal people took that.
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.
This is especially true if you're working on a research task, or the research portion prior to really driving in and implementing the feature. Every day you're basically saying the same thing and it looks like you're struggling, but you're mostly just learning.
I hate it because every approaching standing meeting feels like an approaching "rejustify your existence" checkin.
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.
> In fact, all I like about standups is seeing my team mates once a day
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.
I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how.
According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.
That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.
If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!
Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.
I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.
You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?
Talking about team communication in the abstract is difficult. I wrote a book about it. [1]
The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing.
If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value.
On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible.
Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?
Ping me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients)
You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here.
There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up.
No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.
The only useful result of standups that I ever saw consistently was when people spoke up about tasks they were blocked on, and cross-team collaboration allowed a pathway towards a solution to be established more quickly and smoothly than if the exchange had occurred over email or Slack.
Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.
I famously got outraged at my team the day after our planning meetings + interviews the whole team was on.
"Yesterday we had meetings"
because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.
But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the whole time talking about their thing, and a shyer person might not be able to get in a word that they otherwise really would have wanted/needed to.)
"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.
That is how I view it:
- "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops.
- "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother.
I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management.
As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever.
That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
> As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that.
I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous
damage to any organization.
Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.
Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?
That's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover.
As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly.
In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product.
Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.
I've worked in waterfall and agile for 15 years, and the key lesson from Scrum is that it effectively exposes bad news early on. The scrum ceremonies do just that and nothing more. Once you get the bad news open and dealt with a lot of other work is made more worthwhile.
>Because they show common misunderstandings about Agile
I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working.
People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told.
I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me)
>If you can self-organize, effectively communicate, and help one another as-needed without standups
Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended.
Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.
I'm Old Expert Programmer Dude now, so I get to tell stories.
1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?"
Another coach said nope, we're professionals! What do we need standups for?
The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap.
We did well. He did not.
2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around.
He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster"
He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away.
I smiled as he left and asked him "Wasn't that a great standup!"
"Nope. Could've had that conversation just the same without the stupid meeting"
Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened.
So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)
>And when it works, it doesn't feel like anything has happened
Exactly, which is why it's so hard to keep people on board when all is going well. The meetings start seeming like a waste of time and then you end up falling into cyclic relearning traps.
Good chat though, I'm sure most people who have been SMs will have similar stories.
> The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not.
Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one.
> He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
Frankly, I really don't want to work in environment you and your friends are creating. Regardless of whether I enjoy the process you are pushing for, I don't want to work with people who intentionally sabotage people they disagree with - and then brag about it. If there is something called inability to work with different people, this right here is it.
The pattern I see here is that your colleges are intentionally toxic to those who don't share their preferences and then blame victims. You refused to communicate like adults resorting to passive aggression, not your opposition.
Maybe they were being toxic, but it simply seems like they took a little time in the morning to go over things and he chose not to join them. So what should they have done, each staged separate little talks with him to go over everything that was discussed in their morning meetings? Compile meeting notes and send them to him?
It doesn't sound so much like sabotage as it does that he chose to put his head down and eschew the meeting and struggled because of it.
No, of course not. "We are having coordination meeting at <insert reasinable time and place>" announcement is already fine. Just starting standup when everyone is in office even if he disagree is fine too.
The time and place here seem juuuuust coincide with time and place he is least likely to be at. Standups are not supposed to be passive aggresive way to enforce early coming to work either (most coders have flexible time, your process should honor that) nor are they supposed to prevent you to have breakfast with familly or alone in home.
And yes, if collegue does nor know info he needs for work, I would tell it to him even if he clearly missed it by his own mistake. I would also tell him that he don't know info because he ignores meetings he should be at. Transparency and open discussion, basically.
Otherwise said, you solve it like any other disagreement over something that requires coordination.
I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.
If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental.
With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best.
> due to the business people who are really in charge not wanting to change.
Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
"If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental."
I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies.
"With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best."
Again, not all the issues are ones that the Team directly can address.
"Stand-ups should be only for the team and SM."
Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.
Yes! This is right on the money. So many people forget that "being Agile" is an active undertaking, something that takes reflection and iterative improvement of not just the things you're building, but also the process you're using (in search of a way that works specifically for you and your team). One easy step is rethinking the classic standup questions, in a way to address the overall question "what do you need?".
That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument?
Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer:
"What did I do yesterday that helped the development team meet the sprint goal?
What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?"
These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.
I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.
> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers
Well, they would if there was manager in the daily scrum.
Which is why there isn't.
(Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.
They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.
As a developer, this interaction feels a lot like micro-management.
> If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.
In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.
(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)
If you read the agile manifesto and then you look at scrum, it feels as if scrum has nothing to do with agile. It seems to breaks every rule.
Scrum is processes and tools over individuals and interactions, by its very nature.
Scrum is comprehensive documentation over working software, because you have to map everything out.
Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.
Scrum is following a plan over responding to change, again, by its very nature.
It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:
trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks
simplicity is essential - but we've got all these formal rules for you to follow
working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?
the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules
Scrum is all about implementing a system and then adapting it over time to fit your needs. It's all about having the team figure out for itself how to organize. It's not a rigid set of requirements. It's a set of suggestions about how to begin implementing the system, and then trusting the team to figure out what to adapt and what to cut.
All about what has to be done, with a formal role of scrum master.
Phrases like these brook no adaptability:
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner
on the first day of a sprint and during the planning meeting
Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting
Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.
> I don't find value in anything that agile offers, can I just throw it out entirely by your argument?
Yes, of course?
But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.
But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.
Then it becomes completely meaningless - It's the equivalent to saying to someone - "Be good" without defining anything about what good-ness involves.
Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?
I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process.
I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?
I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?
If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.
Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors.
Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.
Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...
You're basically arguing that CTOs mostly cause damage and it's better to hide various vanity metrics from them with the purpose of them not meddling in the process.
My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.
I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.
I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.
It's so true. So many people think "Agile is bad because my company does ineffective standups". That's not what Agile is! Agile is about continuous improvement.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership
In my experience, at least at bigger companies, standups are there to justify the project manager’s job. It’s for them to tally that everyone is doing their work. Simply, they see that the team wishes to meet for development purposes and it gets co-opted into a status meeting.
I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.
Feel free to send them this way. I’m currently working at a startup where the CEO is the product owner/manager, as well as doing all the CEO duties. A good PM would be a dream come true right now.
PMs have a role, no doubt. They should help facilitate discussion and help protect the team and communicate upward, and provide guidance where necessary. I have worked with some that did this well. I have also worked with some who cared so much about status that it negatively affected the team because they wanted five or more meetings a week (even stand-ups took an hour each). This type of disruption isn't limited to PMs, of course, it's just something I've found in my experience -- more-so than any other role.
You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to murderous regimes, maybe it's better to avoid it than to attempt to "implement it right, this time"?
Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).
This seems like some application of "no true scottsman" combined with complex human interactions in a theoretically "simple" system. I guess the perfectly rational consumer fits in somehow too.
Can you articulate an example of a good versus a bad standup? Because your response is pretty vague. I've been on a lot of teams, read a lot about Agile and SCRUM, and just about every single one communicates stand-ups as a status update, not what you are indicating at all. If this was an isolated thing, I would agree with you, but when almost everyone is doing it this "wrong" way, as you say, I think the problem is with "agile," as loaded as that term is these days.
I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.
Posts like this usually have good points, but I feel like they should always come with a massive caveat:
Every team is different, and you should tailor your processes to fit the team.
And because of this, I think posts like this one should spend time answering:
What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?
The author seems aware of this, because he tries to generalize to just not over-complicating things. But his post is pretty much just arguments for removing meetings entirely without really considering when that might not be a good idea. And there are definitely teams and circumstances where that might not be a good idea.
Not quite. I think there's an important distinction. That caveat says: "I think you should do things this way, it might work for you." But what I'm asking for is: "I think, under these conditions, you should do things this way."
But you're right to point this out. I think I phrased my post badly. The caveat isn't the important part. The second point is the really important one. The decision framework for when to take any specific piece of advice is more important than the advice itself. In general (and this is definitely true with development process advice), advice is plentiful and often conflicting, and most of it gives you ideas of what to do, but doesn't tell you when it's applicable. The really good books, courses, and blog posts I've found do exactly that.
I really like this advice. One thing I've been taking notice of at my job is just how meaningful the tracker is to our workflow. If things are settled down and well-managed, then no meetings are needed, the tracker is a really good representation of the current state of the project, and Shit Gets Done. For awhile when I first joined the team we pounded through sprints and often had a week or more of downtime that we could use to clean up tech debt or play ping pong.
It was Amazing. So amazing I ended up having to speak up at meetings telling our nervous team leadership that nothing was going wrong. We were kicking ass and playing more ping pong than everybody else in the company.
Now we're still kicking ass, but the management has gone into the shitter. We had a product owner, a team lead, and project manager, then the product owner got pushed out and it's been veritable chaos ever since. If anybody is looking for a Rails ninja, drop me a line.
I've had some truly great development managers, and some really mediocre ones. It's helpful to have a technical manager that can shield you from certain issues while still understanding your needs enough to actually meet them.
You said it man. But when development managers enter the picture, and when they're also your people managers, and they come into the scrum and start enforcing top-down patterns it's about as toxic as you can get.
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
Do they ever. Every day I have no idea what I'll actually be working on. It's almost never what I say I'll be working on because shit comes up in a stand-up. I'm not a manager so it doesn't bother me much, but it does slow progress on larger tasks considerably at times. Sometimes I just avoid saying what I think I'll be working on to save time as it's irrelevant and the meeting is already twenty to thirty minutes anyway.
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t.
My team offloaded this to the PM.
> Stand-ups ENCOURAGE plans to change daily.
The sprint plan is the plan, stand-ups make sure the execution is coordinated.
> Standup forces every team member to be productive at a set place and a set time
Timing around standups is interesting. 11am and everyone will be there, but it interrupts a lot of people's flow. Earlier and people no show, later and the point of a morning stand up is lost.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem.
How are extroverts and tech debt related?
> Developers shouldn’t have to PUSH for tech debt to be addressed.
Have a sustainable plan for addressing tech debt. My team had 3 week sprints, 2 weeks code, 1 week on debt. Developers who had just finished a major feature would be cycled on to tech debt for the entirety of the next sprint.
> Why do we encourage problems to be discussed once a week?
You can talk about problems whenever, but having a set place to have larger planning discussions means that you waste less time smaller meetings about them.
> Sprints encourage features over tech debt.
Plan tech debt into your sprints. Put bug fixing onto your task board. Put writing tests onto your task board. If your task board is full of tech debt, then you can't add any more features, because that is how a task board works, it gets filled up eventually and you have to go through it completing stuff.
> It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt
Tech debt sounds like a cultural problem on team's he has been on. Not surprising, it is a cultural problem on a lot of teams, independent of dev methodology.
> Developers communicate more
Why? Developers are always free to communicate outside of stand-ups.
> Tech debt gets addressed
If promotions are based upon feature completion, as they often are, tech debt being completed isn't a natural outcome of freeing up 10 minutes a day.
One goal of stand-ups is for people to say outloud what they are working on, so if someone else has knowledge in that area, that person can overhear and chip in.
Without a public forum, how is Developer A supposed to know Developer B is knee deep in code that Developer A wrote a year ago? Keep up to date on everyone's assigned tasks?
> It’s my role to “steer the ship” (e.g. decide what we work on).
I find that giving developers input on this is important. In fact, that is how the tech debt gets addressed...
> If I’m changing my mind about this on a daily basis that’s problematic.
Yeah, don't do that. Daily standups are not for PMs to give feedback, or talk much for that matter. They are for devs to coordinate the day's tasks.
> Stop planning every sprint
Sprints are super useful to chunk up work and allocate resources. For companies that have infinite investor money and ship a fancy JS app that can be updated at any time without impacting customers, sure, go sprint less.
Have a hard deadline that you need work done by? Does shipping your product have an actual impact on end users? You need to be able to estimate how long work will take, and figure out what people will be doing.
Historical task completion rate, bug fix rates, and burn down charts let teams accurately estimate how much work they can get done before that real life deadline hits.
IMHO weekly planning is too much. My team experimented with a bunch of different sprint schedules, we settled on 3 weeks as a good balance between time spent planning and time spent getting stuff done.
Sprints had a rhythm, developers assigned to multi-sprint features ignored the rhythm for the most part.
For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating with test for sign off.
I'm so in alignment with this. I've always hated standups. As a night owl, it's a morning meeting I have to make every single day and I hate it. I also don't understand how I can't just communicate in Slack to say "hey this is what I'm working on, this is what I worked on. Here are the questions I have." And move on. And if the PM prioritizes the backlog, always pick from the top just makes sense. And yes, retros feel like a place for extroverts to own the conversation (and I know, I'm an extrovert).
I'd guess this is probably only possible at a cash flush company where the devs personally use the product and fully understand the cost/benefit trade offs. Also, those sorts of meetings aren't for the sole benefit of the engineers.
Standups always felt to me that they had a core negative message to developers.
It's not about communication at all. Its about control, its about saying:
We don't trust you.
We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance.
Its also about putting constant psychological pressure on developers, to make sure they complete the tasks as soon as possible, and move on to the next task in the list.
Even if developers know that some refactoring is absolutely needed or this production issue needs a closer look because something strange is going on, developers don't have the autonomy to just do what they know needs to be done.
Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.
Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.
I think it's easy for teams to feel this way depending on the mechanics of who's running standup. One of the biggest values I see for standup is talking through what you're working on. This opens communication with other engineers, especially if they default to working in isolation on their projects (even more so for remote engineers). I can't count the number of times we've had actionable changes to direction from just 5 minutes of standup that result in code reuse, uncovering unknown unknowns, etc.
It's worse than "assembly line worker." For that, a hyper-specific set of actions is created, and then commoditized workers are inserted into this rigid process. The spec/actions rarely change over time.
In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someone is analyzing those actions for "blockers." A "blocker" is either a case where the manager didn't communicate effectively and/or didn't set effective scope/milestones, or else it's a code word for "you're doing it wrong" and gives the manager a change to micro-manage the specific actions the worker is taking day-to-day.
In any case, I firmly agree with you that the core message is "I don't fucking trust you even an inch."
If you want to see a bad engineering manager's brain misfire on cue (if they are of this micro-manager type), ask them why the product manager or designer on your team isn't expected to time-box and pre-estimate his/her spec. writing tasks.
In orgs I've been in the daily standup was clearly intended to help people get a heads up on who can help them with blockers or may be working on a similar part of the codebase that day. It also helps PMs know what kind of support they'll need to give their dev team that day since they often get pulled into meetings by other parts of the company.
As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.
You might be right, but I think you shouldn't be focusing your resentment at standups themselves, you should be focusing on the managerial or corporate culture.
I've worked in places that did standups and places that didn't, and found that the lack of trust / constant surveillance / psychological pressure can be there regardless of whether standups are used.
What does change, though, is that with standups, a manager has the reassurance that they are checking up on their developers every day, and the developers in return get the reassurance that their boss is only going to interrupt them once per day at a fixed time (or at least there's a better chance this is how it works out).
I see "agile" as being a set of compromises and helpful cultural patterns which were designed by taking into account all the weird cognitive biases that brains get forced into by the group dynamics of working in a team on a project.
Standups are one possible solution to a variety of common problems when managing engineers:
- Many engineers prefer to solve issues themselves rather than ask others for help. Often newer engineers don't know when to ask others for help. Standups help to foster this communication.
- Reading code is generally harder than writing code, especially when written using a framework that the engineer is unfamiliar with. This leads to a tendency to declare existing code tech debt and want to re-write it, especially by less experienced engineers. Sometimes this is warranted but often it is not. Standups help guard against this by allowing more senior engineers or managers to catch this early-on.
- There can be valid business reasons to get an unscalable feature out in ~2 weeks rather than scalable feature in ~2 months. Standups provide a quick way to explain the underlying business reasons to the team.
- Business and contracts do require dates & deadlines. Even though it is not perfect, there needs to be some attempt at predicting when a certain feature can be delivered. Jira, and ticket tracking is important for this.
Standups are about developers updating eachother. Basically no one outside the development team should be in the standup. I don't get what's negative about this.
Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they are working in and the wider context it sits in. That is yes, managers don't "trust" developers - but not in quite as negative a sense as you think. There is a positive aspect of supporting the person, ensuring they are connected to the right resources to succeed and stopping them getting stuck on things that don't matter.
I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.
I wish more devs understood what you said instead of taking it as being micro managed. In short, what good managers distrust is the ability to communicate. We are all pretty bad at it. These meetings just give us an opportunity to continually refine what it is we are actually working towards. Agile to me doesn't mean daily standups. It does mean sharing with each other what we've learned about the problem which almost always means reprioritizing. If that communication isn't happening at least a few times a week, there's something off or unusual.
I understand that avoiding spending a week on Y is important for business value, but constantly prioritizing shipping features in the cheapest manner possible also means not investing in the long-term growth of your developers. You don't learn much of value by gluing together a handful of framework functions. You become a better engineer by really struggling with and digging into Y for an entire week. If engineers are never given the freedom to do that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in scrum shops.
That's a really good point. I know my career has nearly entirely been steered from "non-core" activities that I undertook which never would have been justified on a week to week schedule. Businesses also are actually very poor at understanding technical opportunities which developers at the coalface can see (that is, things that are technically easy or at least feasible, possibly due to the specific skill of the engineer(s) in question, but have very high value).
I work on a team where 3/4 of the team are business people. Yet we have a stand up with the entire team everyday and everyone talks about what they are working on. How is hearing that you are talking to account X about something or just came back from conference Y applicable to the job I've been hired to do? Likewise when it comes to my turn to talk it often turns into "blah blah blah [giggle] I don't know what any of that means! computers!" from the business people. It's so useless.
I understand many writers are desperate for views, but I'm looking forward to this nasty spreading imperative title infection to die out (which it will, but not soon enough). "What you need to know about ..." (you have no idea what my knowledge requirements are) "You don't need ..." (you won't know what I need until you find out something about me, dolt). "Why you should ..." (until you've at a minimum skimmed 'Ethics for Dummies', which your 1st-year-uni-essay-think-piece betrays no evidence of, you're not qualified to inform me what I 'should' do).
This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I'm looking at you, Graun), but the tech sector is also succumbing apace.
Now Kant: there was a guy who knew how to construct titles. He did not write "What you need to know about the categorical imperative", nor "Why you must critique pure reason".
I thought the same thing. Not couples therapy, per se - that bit is a blatant straw effigy - but we do have a regularly scheduled chat that is, in effect, a standup meeting.
We've found that it ultimately reduces the amount of time we spend on talking about that stuff. Sit down, take care of business, see what's on Netflix. Without it, we could easily spend the same amount of time per week just figuring out when to talk about XXX thing, let alone actually talking about it.
As someone who hates standups I tend to disagree. I've found that without some kind of forced daily interaction, lines of communication in a team break down very quickly if they aren't already extremely tight knit. Once that happens, your project is toast.
That's funny because we recently started doing standups and our communication has fallen off a cliff. I feel like we had that tight knit group you describe, knowing when to get in touch and when to leave things alone.
Now we don't speak to each other except during standups, and even then it feels more like speaking at each other as it is expected that each member put in their voice, even when they have nothing to useful to add, leading to the team quickly tuning out and then not paying attention when something important is mentioned. Not to mention that now there is up to a 24 hour window before anything is addressed, when the previously used ad-hoc meetings would have got everyone on the right track in a much shorter timeframe. And as a result of all that I feel like there is a lot more animosity between members.
It may be possible to do standups well, but we've failed at it horrifically.
340 comments
[ 4.8 ms ] story [ 287 ms ] threadA retro obligates people to find and/or bring up issues. In my opinion an open door policy would push people to bring up things that actually matter.
If it's the latter, then "priming the pump" is a useful exercise, and a regular retrospective makes tons of sense.
That's also generally true of processes: every team has its quirks, and you fit the processes to the team's quirks.
On the other hand, when you are with a new team, or a team with a few people that need mentoring, or going in a new direction, I find that it's important to force people to coordinate, because many times people will just run off in random directions you don't want them to. You really have to have the best people, and trust their instincts if you follow what the article suggests. Any weak players on your team will just be lost and potentially set you back (or at best, just waste their time).
In weak teams, this could easily see an end-of-quarter with unmet deliverables and other management messes. A lot of people would take advantage of the hands-off approach as much as they could.
Either way, Agile is ridiculous so I agree with the author about that.
Agile is largely about managing weaker teams.
In my world, my team isn't an olympic-performing high-end software engineering pack. They don't lead in particular subfields in FOSS in their spare time. So you know what? They need fucking plans.
This article is a glorified, "Well if you're good you don't need process," piece.
'Bull-fucking-shit' was literally the first word in your comment.
You can find out more about him here: https://blog.ycombinator.com/meet-the-people-taking-over-hac...
> Stripe's? Netflix's? Because they have money
No. Some places have too much money, others enough and then there are those that may have to shut down in half a year. Seen them all, and "engineering aptitude" is completely independent of that.
It sounds like the product your business is developing is scoped too large for the revenue or market share it can realistically capture. Scope according to money available, then your product, and your team, will be happy for it. The business will flourish too, and maybe you'll feel less stress.
Process and communication are kind of key, aren't they?
I think it's often useful to ping people if you know you're going to need their help, for example, but that's not precisely a standup. It's just scheduling and communication.
As for the original post, the outstanding team does not need the manager, so far. It will need one, after the writer deteriorate the culture and communication channels that have been established before him with own "trust" and f-words.
it's still worth reading, not for what it says but what is between the lines. "how not to do sprints". admittedly this isn't (must not be, i guess) common, but at my current $JOB we do dedicate entire sprints to tech debt. remote people phone into our sprints and are well included. it actually HELPS remote contact as there is at minimum a daily interaction with the entire team. (@tapvt had a similar comment.) his comments about changing the course on a daily basis is another example of likely abuse of sprints.
Swearing adds nothing to the author's arguments and I believe you are spot-on on the analysis of the blog post.
Edit:
I missed the following from HN's guidelines
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Sounds very fair. The more you know... :)
The conclusion is relatively sound though: the default agile approach (sprints, standups, planning, grooming, retro) is only a base to start working on a software development project. The team members should optimize it or even throw it out if it works for them.
- Daily standups are a tool for coordinating teams.
- Weekly planning is a tool for iteratively communicating about the progress being done, steering the team and discussing priorities
- Retrospectives are a tool as well; a quorum regarding what goes well and what should be improved.
In a well functioning team, you will always need coordination/communication, progress visibility, continuous improvements, etc.
I picked 2 red flags in how this junior product manager approaches their work:
- the team did not discuss estimations
- he told his boss the team will deliver after 3 months
Basically he just "winged it" for his first project, picked a waterfall approach, and made it. Congrats! That tells me he either has a kick ass team (thank them) or the deliverable was easily achievable (thank the boss), or more likely a bit of both.
Let's take a few of the points being made throughout the post:
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
This is spot on. Using a tool to keep in sync is only useful if the members keep it up to date. If the tool is not up to date, the team either has a tool problem or a people problem.
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
I strongly disagree there. Nothing, in each team member speaking daily, for less than 2 minutes, about what they are working on, encourages change of plans.
When the author mentions standups routinely lasting 30+ minutes... well yeah either fix it the soft way (time limit + a judge making sure everybody stays on point) or the hard way (just stop doing standups & send updates through a different channel).
What I've seen is that there are usually 2 team members that come with the 'authority' to make for a great standup: the product owner (in this case our author) or the tech lead (well, seems it's the author again, as a technical. prod. owner?).
> Standup forces every team member to be productive at a set place and a set time
Yes it can be a problem. That could possibly be reason #1 to get rid of standups. We're lucky in our remote team that everybody is happy starting the day at 9am as standups mid or end of day make not much sense.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
Again, it sounds like standups are being used for the wrong thing. The standup is at 90% a 'passive' communication tool. Listen to the others carefully. Wait for the standup to be finished and FREE PEOPLE FROM THE MEETING to catch up with whomever you want on whichever subject you want.
> Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
Absolutely, problems that can and should be addressed on the spot MUST be addressed on the spot or taken ownership of by a lead and then addressed timely.
However that approach does not catch everything. Retrospectives are an excellent way to make sure people can flag issues. It is natural that, in the week, someone will be too busy to immediately flag an issue, but make a note of what could be improved. A regular open quorum dedicated to these things helps share these details.
There are 2 critical elements to successful retrospectives:
- trust that everybody can speak up ...
"You don't need stand-ups"
I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.
I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.
But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.
The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.
I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.
The list of rituals the author got rid of shows that the team has already learned the more abstract values and benefits and is doing them real-time instead of scheduling them as standalone meetings and sessions. It doesn't mean these things have no value; it means the team is a well-oiled machine.
Except standups. Standups are, have always been, and always will be a waste of time.
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?
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.
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...
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.
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.
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.
"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.
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.
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.
This would be better solved by hosting specific IRC channels for those roles and having occasional role-specific meets/lunches to introduce new people.
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.
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?
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.
(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.)
> 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.
>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_."
Explaining and sharing are important. The difference between micromanagement and management is, IMO, somewhere between daily and quarterly.
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.
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.
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.
Don't take people so literally.
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?
Oh! Just don't give the show people a stage.
You know a stage — like daily standups or so…
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.
They eventually saw the light. I was one of the two people charged with firing the incompetents.
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.
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.
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.
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).
- 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.
Sometimes I’d start meetings with, “first, let’s go around the table and report any surprises this week”, and then adjourn the meeting.
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.
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?
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.
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.
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"...
Get stuck on something for a few days, and it feels like it's time for a new job.
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.
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.
According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.
That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.
If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!
Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.
I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.
The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing.
If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value.
On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible.
1. https://leanpub.com/info-ops
You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here.
There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up.
No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.
Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.
"Yesterday we had meetings"
because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.
I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever.
That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization.
Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.
Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?
As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly.
In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product.
Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.
I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told.
I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me)
>If you can self-organize, effectively communicate, and help one another as-needed without standups
Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended.
Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.
1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?"
Another coach said nope, we're professionals! What do we need standups for?
The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap.
We did well. He did not.
2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around.
He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster"
He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away.
I smiled as he left and asked him "Wasn't that a great standup!"
"Nope. Could've had that conversation just the same without the stupid meeting"
Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened.
So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)
Yes, the pattern is arrogance.
>And when it works, it doesn't feel like anything has happened
Exactly, which is why it's so hard to keep people on board when all is going well. The meetings start seeming like a waste of time and then you end up falling into cyclic relearning traps.
Good chat though, I'm sure most people who have been SMs will have similar stories.
Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one.
> He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
Frankly, I really don't want to work in environment you and your friends are creating. Regardless of whether I enjoy the process you are pushing for, I don't want to work with people who intentionally sabotage people they disagree with - and then brag about it. If there is something called inability to work with different people, this right here is it.
The pattern I see here is that your colleges are intentionally toxic to those who don't share their preferences and then blame victims. You refused to communicate like adults resorting to passive aggression, not your opposition.
It doesn't sound so much like sabotage as it does that he chose to put his head down and eschew the meeting and struggled because of it.
The time and place here seem juuuuust coincide with time and place he is least likely to be at. Standups are not supposed to be passive aggresive way to enforce early coming to work either (most coders have flexible time, your process should honor that) nor are they supposed to prevent you to have breakfast with familly or alone in home.
And yes, if collegue does nor know info he needs for work, I would tell it to him even if he clearly missed it by his own mistake. I would also tell him that he don't know info because he ignores meetings he should be at. Transparency and open discussion, basically.
Otherwise said, you solve it like any other disagreement over something that requires coordination.
If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental.
With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best.
> due to the business people who are really in charge not wanting to change.
Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies.
"With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best."
Again, not all the issues are ones that the Team directly can address.
"Stand-ups should be only for the team and SM."
Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.
This means the tech lead must find something else to do.
Good.
However, all the tech leads I've met think their job is to get up in my hair.
Stop doing it, is what I want to say.
However, we need to show the tech leads what we really need from them.
So they don't displace their activity getting up in my hair.
Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer:
"What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?"
These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.
I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.
Well, they would if there was manager in the daily scrum.
Which is why there isn't.
(Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.
As a developer, this interaction feels a lot like micro-management.
In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.
(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)
Scrum is processes and tools over individuals and interactions, by its very nature.
Scrum is comprehensive documentation over working software, because you have to map everything out.
Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.
Scrum is following a plan over responding to change, again, by its very nature.
It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:
trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks
simplicity is essential - but we've got all these formal rules for you to follow
working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?
the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules
Read something like this:
https://www.mountaingoatsoftware.com/agile/scrum
All about what has to be done, with a formal role of scrum master.
Phrases like these brook no adaptability:
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner
on the first day of a sprint and during the planning meeting
Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting
Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.
Yes, of course?
But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.
But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.
Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?
I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?
I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?
If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.
Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.
Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...
My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.
I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.
I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership
I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.
Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).
I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.
Every team is different, and you should tailor your processes to fit the team.
And because of this, I think posts like this one should spend time answering:
What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?
The author seems aware of this, because he tries to generalize to just not over-complicating things. But his post is pretty much just arguments for removing meetings entirely without really considering when that might not be a good idea. And there are definitely teams and circumstances where that might not be a good idea.
"Notice: Below represents my PERSONAL beliefs about agile and team organization. Your results may vary."
But you're right to point this out. I think I phrased my post badly. The caveat isn't the important part. The second point is the really important one. The decision framework for when to take any specific piece of advice is more important than the advice itself. In general (and this is definitely true with development process advice), advice is plentiful and often conflicting, and most of it gives you ideas of what to do, but doesn't tell you when it's applicable. The really good books, courses, and blog posts I've found do exactly that.
It was Amazing. So amazing I ended up having to speak up at meetings telling our nervous team leadership that nothing was going wrong. We were kicking ass and playing more ping pong than everybody else in the company.
Now we're still kicking ass, but the management has gone into the shitter. We had a product owner, a team lead, and project manager, then the product owner got pushed out and it's been veritable chaos ever since. If anybody is looking for a Rails ninja, drop me a line.
Edit: and so-called development managers!
Do they ever. Every day I have no idea what I'll actually be working on. It's almost never what I say I'll be working on because shit comes up in a stand-up. I'm not a manager so it doesn't bother me much, but it does slow progress on larger tasks considerably at times. Sometimes I just avoid saying what I think I'll be working on to save time as it's irrelevant and the meeting is already twenty to thirty minutes anyway.
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t.
My team offloaded this to the PM.
> Stand-ups ENCOURAGE plans to change daily.
The sprint plan is the plan, stand-ups make sure the execution is coordinated.
> Standup forces every team member to be productive at a set place and a set time
Timing around standups is interesting. 11am and everyone will be there, but it interrupts a lot of people's flow. Earlier and people no show, later and the point of a morning stand up is lost.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem.
How are extroverts and tech debt related?
> Developers shouldn’t have to PUSH for tech debt to be addressed.
Have a sustainable plan for addressing tech debt. My team had 3 week sprints, 2 weeks code, 1 week on debt. Developers who had just finished a major feature would be cycled on to tech debt for the entirety of the next sprint.
> Why do we encourage problems to be discussed once a week?
You can talk about problems whenever, but having a set place to have larger planning discussions means that you waste less time smaller meetings about them.
> Sprints encourage features over tech debt.
Plan tech debt into your sprints. Put bug fixing onto your task board. Put writing tests onto your task board. If your task board is full of tech debt, then you can't add any more features, because that is how a task board works, it gets filled up eventually and you have to go through it completing stuff.
> It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt
Tech debt sounds like a cultural problem on team's he has been on. Not surprising, it is a cultural problem on a lot of teams, independent of dev methodology.
> Developers communicate more
Why? Developers are always free to communicate outside of stand-ups.
> Tech debt gets addressed
If promotions are based upon feature completion, as they often are, tech debt being completed isn't a natural outcome of freeing up 10 minutes a day.
One goal of stand-ups is for people to say outloud what they are working on, so if someone else has knowledge in that area, that person can overhear and chip in.
Without a public forum, how is Developer A supposed to know Developer B is knee deep in code that Developer A wrote a year ago? Keep up to date on everyone's assigned tasks?
> It’s my role to “steer the ship” (e.g. decide what we work on).
I find that giving developers input on this is important. In fact, that is how the tech debt gets addressed...
> If I’m changing my mind about this on a daily basis that’s problematic.
Yeah, don't do that. Daily standups are not for PMs to give feedback, or talk much for that matter. They are for devs to coordinate the day's tasks.
> Stop planning every sprint
Sprints are super useful to chunk up work and allocate resources. For companies that have infinite investor money and ship a fancy JS app that can be updated at any time without impacting customers, sure, go sprint less.
Have a hard deadline that you need work done by? Does shipping your product have an actual impact on end users? You need to be able to estimate how long work will take, and figure out what people will be doing.
Historical task completion rate, bug fix rates, and burn down charts let teams accurately estimate how much work they can get done before that real life deadline hits.
IMHO weekly planning is too much. My team experimented with a bunch of different sprint schedules, we settled on 3 weeks as a good balance between time spent planning and time spent getting stuff done.
Sprints had a rhythm, developers assigned to multi-sprint features ignored the rhythm for the most part.
For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating with test for sign off.
> Tasks are added to the backlog as ne...
Exactly! Nothing about Scrum or Agile discourages tackling tech debt. Managers and Product Owners encourage features—not sprints.
As if to insinuate that extroverts like to increase technical debt and introverts are the quiet ones that toil away. Nah.
At best, this gives micromanagers satisfaction while not doing much, and at worst it's a log of "well I told you so"
It's not about communication at all. Its about control, its about saying:
We don't trust you.
We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance.
Its also about putting constant psychological pressure on developers, to make sure they complete the tasks as soon as possible, and move on to the next task in the list.
Even if developers know that some refactoring is absolutely needed or this production issue needs a closer look because something strange is going on, developers don't have the autonomy to just do what they know needs to be done.
Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.
Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.
In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someone is analyzing those actions for "blockers." A "blocker" is either a case where the manager didn't communicate effectively and/or didn't set effective scope/milestones, or else it's a code word for "you're doing it wrong" and gives the manager a change to micro-manage the specific actions the worker is taking day-to-day.
In any case, I firmly agree with you that the core message is "I don't fucking trust you even an inch."
If you want to see a bad engineering manager's brain misfire on cue (if they are of this micro-manager type), ask them why the product manager or designer on your team isn't expected to time-box and pre-estimate his/her spec. writing tasks.
As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.
I've worked in places that did standups and places that didn't, and found that the lack of trust / constant surveillance / psychological pressure can be there regardless of whether standups are used.
What does change, though, is that with standups, a manager has the reassurance that they are checking up on their developers every day, and the developers in return get the reassurance that their boss is only going to interrupt them once per day at a fixed time (or at least there's a better chance this is how it works out).
I see "agile" as being a set of compromises and helpful cultural patterns which were designed by taking into account all the weird cognitive biases that brains get forced into by the group dynamics of working in a team on a project.
- Many engineers prefer to solve issues themselves rather than ask others for help. Often newer engineers don't know when to ask others for help. Standups help to foster this communication.
- Reading code is generally harder than writing code, especially when written using a framework that the engineer is unfamiliar with. This leads to a tendency to declare existing code tech debt and want to re-write it, especially by less experienced engineers. Sometimes this is warranted but often it is not. Standups help guard against this by allowing more senior engineers or managers to catch this early-on.
- There can be valid business reasons to get an unscalable feature out in ~2 weeks rather than scalable feature in ~2 months. Standups provide a quick way to explain the underlying business reasons to the team.
- Business and contracts do require dates & deadlines. Even though it is not perfect, there needs to be some attempt at predicting when a certain feature can be delivered. Jira, and ticket tracking is important for this.
I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.
This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I'm looking at you, Graun), but the tech sector is also succumbing apace.
Now Kant: there was a guy who knew how to construct titles. He did not write "What you need to know about the categorical imperative", nor "Why you must critique pure reason".
Me: Actually yes - that way it stays amazing...
We've found that it ultimately reduces the amount of time we spend on talking about that stuff. Sit down, take care of business, see what's on Netflix. Without it, we could easily spend the same amount of time per week just figuring out when to talk about XXX thing, let alone actually talking about it.
Now we don't speak to each other except during standups, and even then it feels more like speaking at each other as it is expected that each member put in their voice, even when they have nothing to useful to add, leading to the team quickly tuning out and then not paying attention when something important is mentioned. Not to mention that now there is up to a 24 hour window before anything is addressed, when the previously used ad-hoc meetings would have got everyone on the right track in a much shorter timeframe. And as a result of all that I feel like there is a lot more animosity between members.
It may be possible to do standups well, but we've failed at it horrifically.