When organizations consider or start adopting Scrum, a frequently raised concern is how ‘to scale Scrum’. It is worthwhile investigating this desire, and start exploring the scalability of Scrum.
It seems that many organizations have grown into very complicated and extremely interdependent internal structures over the years of their existence. The implementation of Scrum is expected to fit the existing structures.
Within the existing structures ‘scaling’ is synonymous to increasing volume and quantity, to larger numbers. Hence, the expectation that the implementation of Scrum must be expanded with additional processes, roles, phases, etc.
In order to start thinking about scaling Scrum, there is much value in understanding and employing Scrum fully first. What would you be scaling otherwise, right?
There IS value in maximizing Scrum first.
‘Evidence-Based Management’ for software organizations promotes evidence-based decision-making in the managerial domain to create a more sustainable business through improved services in turbulent markets and businesses.
Scrum.org, which has Scrum as its DNA and empiricism as guiding principle, provides guidance for ‘Evidence-Based Management’ for software organizations.
The aim to deliver valuable software is a great, core principle of the agile movement. The difficulty however is that ‘value’ in itself is hardly quantifiable. Yet, I do believe it is imperative to think in terms of value in software development and therefore overcome some fluffiness attached to ‘value’. If we don’t find actionable ways to deal with ‘value’ it might remain meaningless; another buzz word, another way of getting people to think it’s time to move on to the next hype. It is not only difficult to quantify value, it is not even necessary, maybe even undesirable. It is better to measure whether we are delivering value (effectively).
For many years we were tricked into believing that software development can be considered a success if we meet 3 criteria: deliver (1) all promised requirements (2) within the planned time (3) for the allocated budget. It is reflected in the famous iron triangle of software development.
That in turn tricked us into believing that, in order to be successful, we had to exhaustively analyze, detail and describe all requirements upfront, and get formal approval and sign off over them before the actual programming can be done. The underlying motivation is to secure the first element of what we were told defines success, the ‘requirements’. [Continue reading...]