himynameisdom

I think we're on the same page in our thought process. The opportunity cost of this strike is unclear to those who choose to take part. I'm not hopeful this will bring the change these drivers are seeking.

Hailing back to microeconomics 101, won't this cause a sharp decrease in supply, causing an increase in price and higher wages for those who find it economically-sensible to continue providing service in these cities until S&D equilibrium is met again?

The effectiveness of a retro rests upon the empowerment of the entire team. If the team isn't empowered to own their own success/failure, then there is no point in doing a retro.

From my experience, business units need just as much coaching on agility as development teams. It's hard to change culture, but it's essential the BU gets out of the way (let the team own how they plan on delivering a solution) and facilitates empowerment of change for the team to thrive.

Again, from experience, the main driver of apprehension is middle management feeling the squeeze from making everything transparent. They're use to being the routers (worst case, bottlenecks) of information and work, when in reality their role should be to empower the team with the resources they need to own their work. The shift in focus from delegation to facilitation is essential to the whole process, making retros more effective once realized. Empowerment builds in psychological safety for the team to sink their teeth into their own issues and solve those issues themselves.

Another main driver of apprehension is power within the team. If there are only 1 or 2 main members of the team that dictate the pace of the conversation, that crowds out the rest of the team from buying in and/or providing their insights. The entire team needs to be empowered to own their success, not just a handful of members.

As others have noted, I think it's important to note the difference between Agile and Scrum. Agile is a mindset, Scrum is a framework that encapsulates a lot of Agile tenants. The ideas of a sprint or backlog or cards are purely Scrum. Agile says nothing about using these items to satisfy customers (the highest priority per the Agile Manifesto). That said, Agile principles intentionally include a note about promoting sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

TL;DR So long as you are constantly mindful of Agile tenants, there's already built in awareness around burnout and sustainable practices.

For reference: https://agilemanifesto.org, https://www.scrumguides.org/

> It would seem inhuman not to recognize that some of the chimpanzees' behaviors are deeply unpleasant. And is aggression evil? Yes, I think so, at least when it involves physical violence that is inflicting pain. Violence is the opposite of virtue. I think that a major object of human endeavor and societal ambition should be to reduce violence.

I find this line rather interesting. I feel like there's a whole ball of wax that can be discussed here regarding human observation and the categorization of behaviors based on our understanding of virtue, right/wrong, and ethics.

Man, some of the comments on here are really disheartening. What's the deal with trying to humble people with long-winded, tangential counterpoints, gotchas, and condescending questions? Constantly proving one's intellect seems to be a prevailing theme on HN and I'm not seeing how it adds to the quality of the content. I'm sure someone will unearth the irony in this and let me know soon enough.

This is the core theme behind why Drive Capital threw down roots in Columbus, Ohio. The talent is there, and they're beginning to see the fruits of their patient investment.

As an Agile coach, I agree to an extent. Metrics can be and are often times weaponized by management to exact control over a project.

I wish more organizations saw Agile metrics, or any metrics for that matter, as conversation starters for the team to discuss how things are going and how/when to adjust course. It's a challenge to change habits of making binary decisions based entirely on metrics.

Thank you. I've been humbled.

It's amazing how deleting my account gave me a sense of autonomy over my own thoughts. It took a while, but after some time I didn't care about what other people liked and didn't like.

It's amazing what original thought can do for a person. That little button has more power than most people think.

I believe it was discussed early on when the article states McNamee believed that's when FB started to receive emotional cues from users. But I can see why readers might want a more thorough dissection of that point.

This may be a good place to start: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5739436/

Conclusion: Our results indicate excessive mortality among the homeless as well as the weak and rather typical influence of atmospheric conditions on mortality rates in this subpopulation, except for a greater risk of cold related deaths than in the general population... Deaths caused by hypothermia were thirteen-fold more frequently recorded among the homeless than for the general population. A relative risk of death for a homeless person even in moderate cold stress conditions is higher (RR = 1.84) than in thermoneutral conditions.

Living in Ohio, we're well equipped to handle this. Will be thinking about everyone else who may not be use to these types of conditions. Stay smart, safe, and somehow warm everyone!

I really enjoy reading content that elicits more questions than answers provided. This is one of those pieces and mirrors my experience as well. I lived/grew up in Columbus, Ohio, before moving to the Bay. Columbus has a very nice tech scene, but also boasts industry diversification. I can code, but my neighbors/friends might be in insurance, healthcare, logistics, retail (L Brands) and have a shared standard of living. I ended up moving back and enjoy my $1.4k apartment in a great, quiet neighborhood and 5-7 minute commute to work downtown. I think the Bay Area could benefit from such diversity.

I have to agree with this. What people need to understand is Scrum clearly states the framework itself is not intended to solve your problems. Rather, it's set up to unveil your problems so you and your team can solve them yourselves.

So, if you have a ton of issues while using Scrum, that's actually kind of the point. The real issue is not the framework that unveils your issues, but rather the level at which a team is empowered to fix their own issues.

Scrum is both powerful and useless depending on how empowered teams are to manage their own work. It's really that simple.

I was in your boat not too long ago (honestly, I'm still there but it's become better), and I realized a simple, yet effective way to interact with people without having to a.) talk as much and b.) put your opinions out there for a possible anxiety-inducing interaction.

It really came down to asking good questions. This allows people to help clarify themselves to you without you having to talk too much. It also builds your listening skills, which is probably one of the more important interpersonal skills you can attain. If you ask good questions, people will seek you out. Win-win for your interpersonal and professional goals.

As for resources, I recommend A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Idea. It's a great book with actionable items to help you ask people questions they don't normally hear, which will help people not only understand you better, but help you understand them better. In the end I wouldn't be surprised if this book helps you help other people flesh out their ideas, desires and needs.

I agree. It's amazing how many people on here are blaming the framework for their organization's implementation/interpretation of the framework. There's an insane amount of work going into discussions with people who've been burned by Dark Agile.

Focusing on story points is not Scrum, so why blame Scrum? Rather it's clearly delineated that a Scrum team product owner's main job is to maximize the value delivered through development to the customer. 50 story points means nothing unless the PO has prioritized work that's going to yield the most value to the client.

Scrum isn't broken. It's literally all laid out in a 16 page document. Nowhere will you find mention of story points.

Stop blaming the framework for someone's bastardization of what said framework is meant to achieve.

Scrum isn't meant to solve problems, it's meant to reveal them so you and your team can solve them yourselves. Scrum is a framework and doesn't prescribe any development practices. Rather you use the framework and iteratively insert your own practices and processes, regularly inspecting and adapting those practices and processes over time to fit your goals.

Stop blaming the framework for a lack of discipline.

Scrum isn't a process, it's a framework to utilize your own processes. That's like blaming the framework of the house for a bad paint job.

This is up to the team to help other people understand that velocity/productivity is more than likely decrease as team dynamics change. Even if more people are put on a product, the velocity is expected to decrease as those people absorb new responsibilities. Same story for losing people on a product.

You can lead a horse to water, but you can't make them drink it. I don't know why anyone would blame the water for a dehydrated horse.

Since when is this an excuse for not exhibiting courage to adhere to the framework? Scrum was built on experience, not theory anyways.

Common sense theme here: focus on a small group of people and delight them. If they're having the same problem, chances are others are as well. Be authentic, work smart, and deliver value based on what people are telling you.

To be fair, Scrum doesn't try to capture development time estimates, only the effort needed to provide value. Work items inherently vary in size, or estimated effort. However, enough work should be planned during planning for the dev team to forecast what it believes it can do in the upcoming Sprint. It's all about transparency, not adherence.

That said, requirements emerge daily. Transparency is essential for honest dialogue.

I agree and disagree with the notion that an estimate can only be provided after the work is done. If the work is broken down properly, you can use empiricism to get a good understanding of what is needed based on previous, similar work completed. But to think an estimate can only be provided after the work itself is done is kind of ridiculous. If you section off variables with manageably-sized work you should have a good understanding of what's needed to pull it off.

Most of these problems, such as refactoring, lightweight documentation, and tech debt can be mitigated with a good definition of done and a strong understanding of the sprint goal, whatever it may be.

This is a classic "Scrum" v.s. "How We Interpret Scrum" hit piece.