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.

This sounds a lot like Kanban for Scrum Teams. https://www.scrum.org/resources/kanban-guide-scrum-teams

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.

Why should it be put in the same regime as a combustible if you believe nothing is worse than combustible? Trying to follow your logic here.

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.

Makes sense.

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.

Makes sense. Thanks for expounding on your point! +1

This is misguided anger at best, and trolling at worst. What were you hoping to achieve with this?

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.

I'm assuming none of your SOWs have gone to RFP.

In 10 years of consulting, I've yet to see a client buy this line of thinking. Clients want an accurate forecast for cost and key assumptions being made to formulate that cost. At the end of the day, it's in their best interest to get a good price.

This doesn't mean you can't over-forecast the hours needed in a week to deliver x, it can be an iterative/incremental process. But don't think for a second a client won't want to see how you came up with your pricing model before signing an SOW.

There are two sides to this. Most clients will want some form of cost control on their end. If the final proposal has ambiguity, you best bet the client's procurement team or relationship manager will want to discuss this. They have people they report to as well, and it's in their best interest to get the best price. The forecast has to have some form of predictability/reliability, otherwise prospective clients will simply stop returning your emails.

There are two (or more) sides to every story. Would love to get a full 360 perspective on this scenario.

My apologies for making an assumption on my part. The irony of doing so did not get past me :)

Fair point. Interested in seeing how this all plays out.

The main basis of opportunity cost is knowing both outcomes of each decision and choosing the outcome that makes the most sense based on resource scarcity (ability to both strike and work at the same time in this case). While they may very well know how much money they'll lose by not working those 12 hours, they certainly don't know the true cost and gain of the same decision, thus making the opportunity cost unclear.

That's really the basis of my comment. It's not an assumption, it's quite black and white.

Great point. I guess my line of thinking was scoped to Uber alone.

I appreciate the note, but please don't infer passive-aggressiveness when all I was seeking was clarity.

To be clear, are the "rats" those who believe it to be economically-sensible to continue working or those who choose to follow through with the strike?