himynameisdom

Emotional intelligence. Specifically: self awareness, self management, social awareness, and relationship management.

The whole point of a stand up (daily scrum) is to discuss how work is progressing towards a sprint goal. If it devolves into a card-by-card status update meeting, it loses its value.

It is nothing more than the dev team coming together to discuss how to move forward towards the goal. No one else should be at the meeting. If further detailed discussion is needed, save it for afterwards.

It is worth noting that ALL the agile values you spelled out are actually important. That said, the values on the right do not take precedence over the values on the left.

Processes and tools are important so long as they don't diminish individuals and interactions.

Documentation is important so long as it doesn't get in the way of building software that works.

Contract negotiations are important so long as they don't get in the way of a collaborative relationship with customers.

Following a plan is important so long as it doesn't get in the way of responding to change as a competitive advantage.

I've ran into this with teams before. I think it's critical to ask ourselves "Who really are our stakeholders?". More often than not, the answer boiled down to a.) our customers and b.) our sponsors. If someone from sales, marketing, support, infra, or anywhere else lobbies for anything that'll turn into work, we work with our PO to make sure this is something the product team (customer by proxy) or sponsor(s) really think are important.

Time and time again we've butt heads with the sales team because they promise the world to one or two leads before checking back in with reality. Those interactions are met with checking in with stakeholders to validate assumptions. we gained the support of our executive sponsor or customers who are actually paying for the product to be built. Asking that question insulates us from greasing internal squeaky wheels.

Since pipenv is pretty much dormant, this seems to be a nice alternative. Thanks for sharing!

Same here. I moved into Agile/DevOps coaching, where it's expected you learn in order to help your teams grow and improve their practices and products. Haven't looked back. I now spend a lot of time advocating on behalf of my teams to get them in-sprint time to learn and mature what they're interested in.

I've taken the route of a "build your own MBA", seeking out various industry certifications to validate my learning. I flirted with an MBA program for years, but none offered the flexibility I was seeking in terms of honing a skillset around what I'm going for in my career.

Agreed. Vision and strategy set the table for why and how the work moves towards an intended outcome. Every company I've worked with that does scrumfall tends to value outputs over outcomes of the outputs.

The process name doesn't matter, the results of the process should be the focus of every product company.

Agreed. Look no further than the iPhone.

If the team isn't relaying how their work is progressing towards the sprint goal, the daily scrum ends up turning into a status meaning, negating its intended purpose.

The daily scrum is a planning meeting. It's meant to help the team understand the big picture scoped to 1 sprint while helping each other achieve a shared commitment.

I would agree the word "sprint" can conjure up a bad picture, but the agile manifesto clearly states the team should work at a sustainable pace. Nowhere in the Scrum Guide does it say you must work at a breakneck speed.

Inputs for sprint planning include the relevant empirical data (velocity, burn down/up etc.) to help with planning. In my experience, these data points are used to measure productivity, which is dangerous. Companies end up measuring success by outputs, rather than outcomes.

Business units need to stop weaponizing Agile and realize they too need to change in order to inspect and adapt towards building things people want.