Get in, do the work as simply as possible, and get out. I’m being simplistic here (while discussing simplicity, no less), but this is the way teams need to look at development.... complexity leads to unreliability.

feature team is organized around delivering features instead of focusing on requirements. A feature team delivers complete, working, vertically sliced software each iteration—just like a Scrum Team. The difference is that a feature team works on features end to end, feature after feature. In other words, the team works on the feature until it is complete, delivering vertical slices each iteration. Once that feature is complete, they move on to the next feature. The team has everything it needs to complete the feature. It has the necessary skills, tools, and authority....
While feature teams try to slice stories vertically, component teams are more horizontal across architectural boundaries

In Agile, the QA engineers are no longer the victims. They are the leaders. They own the quality in an environment where zero defects is the policy, not a target. Testing should be done as early and as often as possible. Agile teams are required to release with zero defects. This means exactly what it looks like: QA must be taken seriously. What’s important is releasing the highest-quality product possible

The PO acts as a buffer between all of these people and the Scrum team. For example, if the legal department requires the team to publish an end user license agreement for some third-party software they are using, they don’t go directly to the team. They go to the PO, who will put that requirement into the Backlog and make sure it is properly prioritized. That EULA (End User License Agreement) may not have to get done right now, but it needs to be done before the product is released. This allows the team to focus on the task at hand and not be bothered by external influences. The team is shielded because the PO takes their requests and creates a Backlog of user stories....
It is important to note that once the Sprint Backlog is set, nobody can change it...
They still have the pressure to complete something by Sprint end, but only what they have committed to. Look at it this way: If I tell you I am going to do something, I’m invested in it. It is not the same if you tell me to do it.

We are being as transparent as possible, so account for any holidays, planned vacation, or anything that would prohibit work from getting done...
Sprint Retrospective meeting as a closed-door, locker room meeting for the Scrum team....
The meeting must not be a complaint session. The Scrum Master must ensure that there is positivity in the meeting. Allowing the team to go negative doesn't solve anything. Yes, they may need time to vent; however, the purpose of the Sprint Retrospective is to inspect and adapt. Limit the amount of bad stuff discussed, highlight the positive, and decide what to change or experiment with to get better.

The team should strive to have two or three Sprints’ worth of stories refined. Remember, a Scrum Team should expect change. There is no reason to have three hundred stories refined—unless the team can get that done in three Sprints. If the team expects change, it expects priorities to change radically from Sprint to Sprint.

When a team member says what she plans to do today, she is making a commitment to her team...
Anything blocking a team member's progress is addressed by the Scrum Master. This way, the team member doesn’t have to worry about handling the issue. It is now the Scrum Master's responsibility. The team member can now focus on Sprint work. For example, if a team member is having issues with their laptop computer, it is brought up as an impediment at the daily stand-up, and the Scrum Master takes care of getting the laptop repaired....
If something comes up that goes beyond the spirit and intent of the daily stand-up meeting, it needs to be moved to the parking lot. The parking lot is where the team “parks” subjects to be discussed later. I usually hang a big piece of paper on the wall where the team holds the daily stand-up meeting and put sticky notes on it when a parking lot item arises.

In a recurring revenue business, there's no such thing as post-sales. Every single activity is a pre-sales activity.

Because the job of customer success is to make sure customers are deriving success form your product, they are a revenue-driving organization. This means they need to be people who are at least sales-savvy, if not having direct sales experience.

Customer advocacy is used most often to describe the critical role that happy and successful customers can play in advancing a vendor's agenda with references, case studies, positive reviews, and user group participation.

Customer Experience (CX) typically refers to the assessment and management of the overall customer experience across a customer's lifetime.

the key metrics are by which success will be determined: gross renewals, net retention, adoption, customer health, churn, upsell, downsell, net promoter score (NPS).

customer success... requires a to-down, company-wide commitment to trylly deliver world-class customer success.... There are three basic benefits that come form executing customer success well: reduce/manage churn, drive increased contract value for existing customers, improve the customer experience and customer satisfaction.

normal two-week Sprint has nine working days or 45 available hours per person (ten five-hour ideal days minus one day for end-of-Sprint demo and Sprint retro

Usually the suggestion is that everybody must put at least one note on the boat, but no more than three.

The burn-down chart should be shown to the team daily. It gives an accurate indication of how much work is done, and it does a good job of predicting whether the team will finish all of the work it committed to for the current iteration.

During the Sprint Planning meeting, the team looks at the story and breaks it into tasks. Tasks are segments of work and are figured in hours. But not as you would think. Agile teams work in “ideal days.”...
In ideal day for a software worker is about five hours...
Truth be told, we never sit down and spend eight hours a day banging out code or testing. We go to meetings, deal with our email, talk to our teammates about design or trouble we are having with what we are working on, attend town hall meetings, get coffee, visit the restroom, and a bunch of other stuff I won't detail here. The five hours should reflect how much time we spend actually working on user stories a day.

In Agile it’s much easier — the standard is “zero defects.”...
The idea is that a defect does not increase in value over time, but it does increase in cost, exponentially.

As a team member, you should always be looking at how you can help the team achieve the Sprint goals. That might mean that you jump in and do some testing or help write some code for a story that hasn’t been completed yet.

Managing work in progress (WIP) is a sign of maturity. For some reason, most people want to start working on everything at once. I call this the curse of multitasking. Yes, we live in a time that seems to demand that we multitask, but in my mind, it's more valuable to get stuff done. Getting stuff done requires that we focus...
It's better to have fifty percent of your stories one hundred percent done than one hundred percent of your stories fifty percent done.