We have trained thousands of individuals in Scrum and worked with literally hundreds of teams as well.  When you add in the hundreds of conversations we've had at the dozens of conferences we've attended, I'd say it's a fair statement that we've seen a lot of what goes on with teams adopting Scrum. Over the last 10 years of using Scrum we've seen many patterns in how well (or not) teams do with it.  We believe many of the challenges that Scrum teams face - plateauing, inability to scale or even not being able to get it to work well for them - are due to their lack of awareness of certain key principles and concepts. 

This page specifies these basic concepts and practices we think virtually every Scrum team should know.  We've selected those that come from years of experience of assisting companies of all sizes in Lean-Agile adoptions. The importance of being aware of these principles and following these practices may be less for small teams - but we strongly suggest considering them as ways of improving your Scrum implementations. These practices are based on Lean Concepts all Development Teams Should Know .

Core Principles ("laws of software development") to be aware of

Just like gravity is important for airplane designers, these 'laws' affect software development.

Delay cause waste.  Watch this 12 minute video explaining how and why this is a central tenet of lean.That delays from when information is gathered until it is used or from when an error occurs until it is detected literally creates extra work is readily confirmed from your own experience.  Minimizing these delays is a key method to improved performance and quality. 

Working on too many things increases delays that cause waste.  This should be self-evident.  This is why managing how many things in play at any one time is so critical.  "Stop starting and start finishing" is a solid mantra. 

Optimize the whole. Improving one aspect of your development process can often hurt the overall performance of your organization.  It is critical to consider the entire value stream - that is, the workflow from when work starts until it is consumed by the customer.

Understand the importance of the Minimal Marketable Features.  See an 11 minute video that explains what Minimal Marketable Features are and why they are essential to Agile methods. 

Managing your product portoflio properly can vastly assist your teams.  If teams are overloaded, making them more efficient may not be enough.  You likely have to get the PMO to understand that they can get more productivity out of their teams by providing them with only the essential projects to work on. 

Practices / Attitudes all Scrum Teams Should Follow / Have

1. Use acceptance test-driven development on all of your stories
2. Plan ahead enough to enable all stories in the iteration to have had acceptance tests written at the start of the iteration, but no more
3. Have a vision statement for your project
4. The product owner should act like a champion leading the team to discover what needs to be built, not a dictator of what to build (nor should he fear his neck might get wrung)
5. Use Minimal Marketable Features (or their equivalent), not epics, to guide stories being pulled off the backlog
   

1. Keep the number of MMF's (Minimal Marketable Features) open at any time to a minimum
2. Keep the number of stories open at any one time to a minimum
3. Make all work visible
4. Have the team discuss how they make decisions on a regular basis – having explicit policies is much more effective than people just using their judgment at the moment.
5. Have your Sprints be no longer the 2 weeks in length
6. Have all stories be no longer than 3 days (1 is better)

1. Have the team know both Bochman's Team Estimation and James Grenning's Planning Poker

1. Treat management as allies, not lepers
2. Managements role must include removing impediments the team is facing
3. Have a dedicated ScrumMaster until the team coalesces 
4. Have the ScrumMaster be more coach than facilitator

1. Have an explicit definition of what done means
   
2. The team should have a basic understanding of how delays cause extra work
3. When deciding on how to do things, use economics and cycle time (time from start of feature to consumption) as the main drivers
4. Learn the Lean concepts all teams should know 
5. Really do retrospections - don't let them become stale
   

1. Attend to quality coding practices (e.g., design patterns, refactoring)

1. One must recognize that Scrum-of-Scrums only works when teams are being measured in the same way
2. Have multiple teams that need to coordinate with each other, pull off stories that enable shortening the cycle time of the combined stories (and keep the amount of stories open across the teams be as small as possible

1. Manage your work in process levels explicitly (remember it's a measure of the work, not the people, so even when you swarm you can have WIP limits)
2. Have your ScrumMaster understand Lean and Kanban. This knowledge will help in many situations

1. When your work items are so small (e.g., you do maintenance) it is probably easier to do away with Sprints altogether
2. When your delivery is more frequent than your iteration (e.g., a media company) then you probably don't want Sprints either
3. If you need people who have specialized skills, knowledge of legacy code or have deep domain knowledge that need to be shared across team