In this post I am going to single out some specific passages from the Scrum Guide, as I think they are helpful for understanding some prerequisite conditions for Scrum to be successful. They may even cut to some challenges you are having with your team at the moment.

I’m amazed at the number of people in the “real world” (not in the little Agile bubble I inhabit) who have “done Agile” for years, but who have yet to read the Agile Manifesto and the Scrum Guide. A lot of the “how to” — the tools and practices — are passed down through tribal knowledge. Given that what you are doing probably borrows, to some degree, from Scrum practices, and that Scrum and Agile are related (but not the same thing), I highly suggest you read these two documents.

For the record, I don’t see many teams doing Scrum by the book: some to their detriment, and some to their advantage. Below I am going to mention some things “from the book” that I do find valuable.

A couple weeks ago, I wrote about some common challenges with Agile.

Why Isn’t Agile Working?
A couple drawings…hackernoon.comReflecting on that post, I realized that some of the core challenges are covered in the Scrum Guide. The Scrum Guide makes a number of statements that sound like prerequisites (though they aren’t called out as such). Recently, I argued that it is is important to make sure that you create conditions conducive to the success of the Agile and Scrum on the team level. I went as far as to say that it isn’t even worth installing process on the team level until you address broader issues.

Stop Obsessing Over “The Teams”
Sound familiar?hackernoon.comThere are countless teams “doing Agile” who have never read the Scrum Guide. They may be working their ass off to make it work, but something feels off. They may even be blaming themselves — or “Agile” — for the problems they’re having. And there is something off! It is highly likely that your situation isn’t meeting some of the basic pre-conditions for success spelled out in The Guide.

Hopefully, armed with this information, you’ll be able to make a case for reducing dependencies, increasing autonomy, limiting distractions, increasing psychological safety, reducing meddling, and bringing in dedicated help from required competencies. The Way you are trying literally calls out these things as requirements for success. No one may have told you. Now you know.

1. *Everyone focuses on the work of the Sprint and the goals of the Scrum Team.** *Meaning: The team has no other responsibilities like doing piece-meal work, getting called into unrelated meetings, etc. Everyone — that means everyone, including the Product Owner — can focus 100% on working towards the sprint goal. Every day must have large blocks of uninterrupted time to collaborate and work diligently.
2. *The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work | Scrum Team members respect each other to be capable, independent people.** *Meaning: A high level of psychological safety must be in place. Team members cannot be afraid to voice concerns about: managers, each other, Scrum itself, goals, technical debt, the company, progress, risk, tools, etc.
3. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team | Development Teams are structured and empowered by the organization to organize and manage their own work | No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality Meaning: No one outside the team tells the team how to do their work (and organize and manage their work). The team is not dependent on other teams to do its work.
4. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. Meaning: The team cannot rely on outside competencies. ALL the competencies exist on the team. If needed, UX is on the team, Data Science is on the team, Analysts are on the team, QA is on the team, Domain Experts are on the team, and Operations is on the team.
5. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available | The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Meaning: There can be nothing obstructing the team’s ability to produce a Done increment by the end of the sprint. Example obstructions might include interruptions, handoffs, lack of access to the customer, etc.
6. For the Product Owner to succeed, the entire organization must respect his or her decisions. Meaning: When the Product Owner makes a decision, everyone — the CEO, CFO, VP of Sales, VP of Marketing, engineering managers, everyone — must respect the decision. This implies that the Product Owner also has enough experience to make decisions people will respect.
7. Accountability belongs to the Development Team as a whole. Meaning: Individuals must chip in to help their coworkers. Individuals are not individually measured. There is no such thing as [Team Member X] finishing their goal. No team member should have to juggle/reconcile their own performance management goals with that of the team.
8. During the sprint, no changes are made that would endanger the Sprint Goal. Meaning: No interruptions, either internal or external. So…how can you work to create these conditions? This might be the best use of your teams time.