This past fall I visited some of the biggest tech players in Silicon Valley (PayPal, Twitter, Salesforce, Wallmart.com etc.) There were two take-a-ways from those visits. First, people, mostly leadership, wanted to know how to scale their Scrum implementations; and second, teams weren’t getting testing done inside the Sprint.
I’m heading back to the Valley in mid February to teach both a public CSM and CSPO course as well as a one day Scaling workshop and I plan to address these two issues head on.
Scaling: More scaling frameworks come-online everyday. Most I find overly prescriptive and limited in their efficacy. However, frameworks like SAFe are a good starting place for companies with very new implementations.
It’s important to remember that Scrum was designed to scale. The first time I scaled Scrum teams at IDX in the mid 90’s it became really clear. Scrum is based on modular or object oriented architecture. It allows multiple teams to swarm on all modules simultaneously without ripple effect. This is called all-at-once-Scrum and it was the team model Nonaka and Tachieuchi highlighted in their HBR paper that inspired Scrum. A truly effective Enterprise Scrum should be modular in design. The Scrum Inc. team has developed a scaled framework that allows companies to plug-and-pull the modules they need based on their specific context.
What is your context? Are you in a large mature industry like a government contractor? Or, are you a successful software company feeling innovation nipping at your heels? Depending on your vision, needs and industry, you will probably want to prioritize certain scaling aspects before others.
Test Inside the Sprint: Quite possibly the most important aspect of Scrum is the feedback loop. The team demonstrates working software to all the stakeholders at the end of the Sprint. The stakeholders try it out and then give the team feedback on possible improvements. Continuous improvement is really the end game here so without working software, the Scrum process breaks down.
It has to work to get feedback. You won’t know it works until you test it.
If you aren’t testing inside the Sprint, you don’t get feedback from your customers and stakeholders at Sprint Review. Feedback you need to assess what they like, what they don’t, and make changes early.
Testing is tough and a lot of teams don’t feel like they have the skill set or the opportunity to test within the Sprint. Bring you testers onto the team. Use out-of-the-box tools and develop a testing regime incrementally. With clear goals and a motivated and focused team, testing can get done before review.
-- Jeff Sutherland
English 
French 
Spanish