Creating software with Scrum is difficult. Creating one integrated piece of software with multiple Scrum teams is a managerial and technical drama, requiring sophisticated techniques, tools, and collaboration.
In my last two blogs, I shared my opinions about the skills and knowledge to scale Scrum. I could be wrong, but in my experience many people in software development don’t have the required skill and knowledge. Twenty years of failure and success have been required by practitioners like Jeff Sutherland and myself to learn them.
But, that is just my opinion. In my last blog I offered you an assessment to test your knowledge of scaled Scrum development. The assessment was open to anyone. The questions were only of medium difficulty, probably less hard that what you will run into in real life.
In less than a month, 19,042 people have taken assessment. The average score is 54.2% correct.
Just as Conway’s law reasons that software interaction is a reflection of the communication of the programmers that wrote the code, I assert that the the average assessment score of the developers and managers on an initiative would be reflected in the quality and value of the software developed.
I’ll be posting a full assessment of the knowledge needed to scale Scrum in late December. Between now and then, we are conducting workshops to help you learn how to scale Scrum for your unique circumstances, and to develop a plan to do so. I strongly recommend you attend. You’ll learn how your organization can professionally scale Scrum initiatives. You will also probably improve your score on the assessment.
For the New Year, I toast the improvements we have all made in the profession of software development.
Ken Schwaber's Blog: Telling It Like It Is 
Pingback: Scale Scrum Development, not Technical Debt - The Agile Product Report
You entitled this entry “Scale Scrum Development, Not Technical Debt”. Why? I might be missing the obvious, but want to ask.
Scrum at Scale involves multiple teams working in collaboration to provide a fully integrated and potentially releasable increment. This stands in contrast to a stage-gated approach where increments are batched prior to integration.
Integration, and any other work that remains to be done before release can be effected, can be seen as a form of technical debt. There are many cases of organizations trying to “scale” agility-in-the-small without changing their technical environments and big-bang release culture. Hence it can be argued that it is the debt, and not the agile practices, that achieve scale. I suspect this is what Ken is referring to.
I got 90% from my 10 questions and I was hoping for a badge 🙂
I hereby give you the badge you already had: satisfaction.
Ken
Best Christmas present ever =:-D
Pingback: Review Jeff Sutherland - Scrum: The Art of Doing Twice the Work in Half the Time
Uh yeah, I fail to see how this post is about technical debt. I don’t expect click bait from a person of your stature. Its about the results of your assessment, which are really interesting.