Hacker News Reader

A good team can make any process work, just like a bad manager/team can destroy the best process.

I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management).

I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up.

I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed.

Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.

>>> I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career.

I'm curious how bigs were your teams? and if you were all local in the same office?

There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.

10 or less people, mixed in office and remote. Mine have almost always been fairly informal, and early on (I'm in my 40s) pre-agile it was just a what's up type thing. So while there was a scheduled time, it was a very free form meeting. We would talk a bit about work, last nights video game, etc... If people were already deep into some work, it was fine to miss.

Agile/Scrum is great if done properly.

Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work.

Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.

> Agile/Scrum is great if done properly.

and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects.

Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time.

Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.

Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures.

It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition.

But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings.

I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.

> Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.

These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.

How so?

You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)?

In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation.

I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with

> your IT department

If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center.

> It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with

Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.

> Agile was written at a resort by 10x engineers for 10x engineers.

Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation.

Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.

Nobody does the full Scrum.

It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.

One of the details of the manifesto is that it does not tell you how to do things, and in fact discourages the prioritization of "processes and tools" over "individuals and interactions" (doesn't remove processes and tools, but it deprioritizes them). The manifesto was as much for the developers as for their managers and customers. It established the priorities of their work and relationship with each other.

And people can only communicate fluently and organize seamlessly because of their understanding. There's no quickfix solution to making sure you hired the right people.

> Agile was written at a resort by 10x engineers for 10x engineers. Do these 10x engineers need Scrum ?

Not to beat a dead horse one more time, but "Agile <> Scrum"

Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum.

And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto.

And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.

The only time I’ve seen it done properly was a team I worked in before the Agile manifesto was written.

Honestly I feel like a team that communicates healthily in channels on slack kinda defeats the entire purpose of stand ups. At my current job, we even have the customers for my team in slack channels and they are highly communicative, so honestly it makes the whole scrum model seem just a waste of time when I can start a question/thread right in slack with the product owners/customers

We have a #daily-updates channel where we can just drop status and blockers. We roll it up into a weekly summary.

According to Scrum, the manager should not even be present during the daily stand-up.

(More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.)

> I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next.

In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time".

> One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible".

This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".

I thought this way when I started working, but I'm grudgingly coming around. It's easiest to keep a house clean out of respect for the people you live with. It's easiest to consistently dress and groom well when you're meeting people whose opinions you value. It's easiest to stick to exercise when it's an appointment with other people. You will cook and eat best in social and family meals.

A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.

At my last full-time position in the corporate world we were doing Scrum well. The daily scrum was short and not for any manager - team members shared quick updates and blockers with each other. Before we had Scrum enforced, all the dev teams suffered from chaos caused by product owners constantly changing priorities mid-sprint or adding “just one more feature” several times during the sprint, so once the product owners agreed to stick to Scrum the team was able to enjoy some sanity in their work.