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.
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.
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.
Ban e-cigarettes until they're reviewed by governing bodies. Continue to sell combustibles that've already received a negative health review for both those who consume them and those in the general inhalation vicinity by said governing bodies.
I agree. I enjoy speaking to prospects and clients, but I know not everyone feels the same way. I would say instead of letting technical people handle the client/user, it should be done in a collaborative way. Filtering shouldn't be necessary as that has the potential of keeping possible problems/solutions in the dark.
Technical and nontechnical people should collaborate face-to-face on a daily basis. That includes customer interactions.
i think now more than ever, there needs to be a bridge mindset between technical and non-technical. i learned that very early on, and even spent some time in a customer-facing, non-technical role to hone my bridge mindset. the ability to have empathy for the end user, and everyone else upstream who will touch your logic, is paramount and takes care of a lot of issues.
it's up to us as technical professionals to care about both the "what" and the "how". the ability to pan in and out on a particular need was learned early on and i cannot be more thankful of that.
GK, I remember your presence on that thread. For those who were not there, it's under comment history. You spoke to the point of people needing your help (and not just anybody), which is kind of ridiculous in this case and the case from last week. You're opining value-driven fixed rate wisdom on a thread about a simple HTML page. If you dictate the pace of a specialty, of course you can charge whatever you want and call it "value-driven." For the other 99% of consultants out there, supply and demand bring pricing to an equilibrium. Retainers need not apply here nor in 90% of first-time client engagements.
Consultants who win the job will always leave money on the table. That's how you get the gig to begin with. Value is relative, and it takes at least two to tango come contract time until cost (what the client sees) and value (what you see) intersect.
Billing hourly brings pricing transparency clients want while protecting you from true under-utilization. If you're not being utilized because of red tape that was unassumed at contract time, a change order is the logical next step to account for scope remaining/additional scope.
Are you saying those who go to RFP to keep cost control transparent really don't need the help? It's also kind of egotistical to assume a company needs you and you alone to solve their problem. If the problem is big and important enough, rest assure there's more than one shop that has an idea as to how to fix it.
I also think we're talking apples to oranges. A one person shop may approach contracts differently than a shop with 13 across 3 time zones.