The primary goal of Scaled Professional Scrum

Last post 04:17 pm September 13, 2019
by Tony Divel
1 reply
Author
Messages
03:28 pm September 13, 2019

Hello all, 

I have been working towards my SPS certification and I stumbled upon the following question during one of the mock tests on thescrummaster.co.uk 

The primary goal of Scaled Professional Scrum is best described as:

  1.  To keep the scaling as uniform as possible. As your costs rise your productivity should rise at as close to the same rate as possible.
  2.  A framework to allow you to achieve linear scaling from a productivity/cost perspective.
  3.  A methodology to help you scale your software development.
  4.  To allow you to develop software at scale.

I need some guidance on this question, maybe I am not reading it correctly or the semantics are tricky for me. I am struggling to connect SPS with cost and productivity perspective though the Nexus guide states

When software delivert using scrum is scaled, these dependencies of requirements, domain knowledge, and software artifacts should drive the organization of the Development Teams. To the extent that it does, productivity will be optimized.

and I also feel it is not a methodology for that matter. However, when I choose option no.4 (since I feel it is the most dressed down goal as per the Nexus Guide). 

Could the experts shed some light on this? 

Thank you 

04:17 pm September 13, 2019

I feel like that third party site might be missing the point. I don't necessarily agree with those answers...they also use the word scaling to describe the goal of scaling. 

The excerpt from the Nexus Guide you listed hints at the goal more than the practice question in my opinion. To me, if we think about why we would even want to scale the Scrum Framework it goes back to delivery an integrated releasable product increment. 

If we decide to have multiple teams working on the same product...what might happen if we don't scale our feedback loops and inspect and adapt events between the teams? 

More people means more challenges with dependencies, communication, etc.