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.
How many teams are actually organized in this way, though? I've never been on a dev team where there was a single, unified sprint goal that all developers were working towards in an interrelated way.
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.
If the sale is easy it’s because the lead thinks like your existing customers. If the sale is hard, it’s because they don’t.
Any feature you use to entice a new customer isn’t necessarily going to please your existing base. It might, as someone else suggested, actually be a considered a liability.
So the idea of building a new expensive feature, or a new feature in an expensive way, is suspicious. There’s no guarantee you can amortize that cost across all of your customers. And the times we really butted heads with sales? The features cost us more than the value of the sale, reducing margins.
But I suppose that’s the sort of metric dysfunction you invite in when you measure salespeople by sales.
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.
Sorry for being too direct, but for the sake of clarity, and coming from my experience communicating with agile coaches - I think it is bullshit. I wonder if others have a similar experience/opinion...
Personally—I think because I've seen so little of the code I've written actually live long enough to seem worth the time it took to make it, including a bunch of small-potatoes projects for huge companies that took months of my work-life and then were simply binned because they changed direction or acquired some company with another solution or the project was doomed from the start because they'd very obviously allocated far too small a budget—I'm no longer turned off by the idea of having a job that's more-or-less understood to be entirely bullshit, the way I might once have been.
How did you make that transition? I've been interested in making a similar one but have been frequently advised to stay in engineering and work my way into management instead.
The thing making me want out is having to change jobs every few years not to fall way behind on current pay, and having, for interviews, to prep for a series of goddamn pop-quizzes in a high-pressure environment, which could cover material from any or all parts of your education or career, plus a bunch of stuff you may well never have encountered in either, at practically any difficulty or granularity level, with, usually, no way to narrow the field you need to prep for down meaningfully even if the roles you're applying for are pretty specific, and usually with no clear understanding of how your performance will be judged. It's the only thing I've encountered in adult life that gives me stress-dreams like school did. "Normal" job stress, even when shit's on fire, is about 10% as stessful, at worst. I hate, hate, hate it.
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.
