Ashby, Complexity and Scrum
Dear Scrum.Org Community,
the team and I are living scrum and nexus on a pretty good level. Nevertheless, I have identified a major weakness from a systemic point of view: The issue of complexity.
In my experience scrum in its form does not protect against one-sidedness and blind spots. On the contrary, value is once misinterpreted, e.g. as "economic" success or only value for the customer - and you may miss things like innovation or software architecture.
I like the four value fields of Evicence-Based-Management very much. They convey a complex and holistic view of the value of a product - and, in my understanding, should be reflected in the backlog.
My request: Does the Scrum Guide make strong awareness for complexity and value from different angles? Without an uplift of complexity, agile (in the end) is not worth anything because too many blind spots are and remain in the system.
Please build Ashby's Law about requisite variety more into the Scrum Guide, e.g. in the Backlog, in the Planning whatever...
At the end of the day everything is about handling complexity (and Scrum is very good at handling that). But if the awareness for the importance of complexity is not there, the most beautiful agile framework is of no use.
What do you think? I like to hear your opinion on that :)
The challenge with the Scrum Guide has always been what can we take out, not what might we put in. That's my observation. Every time we include a prescription we rob people of the ability to apply the framework intelligently in their own context.
Yes I see the point, thanks. But the thing: Be divergent in filling your Backlog and the be convergent by prioritising (in Backlog Prio discussions and the planning) and have a holistic / complex view on your product is sometimes? often? missing.
So for me the words: 'holistic view' (in terms of value) and be 'divergent' and also 'convergent' e.g. in the planining (see double diamond) are missing in the scrum guide. Because these things / this way of thinking is fundamental for doing agile.
In my opinion in the end it is all about steering complexity.
Hi I found a very good article according to this topic = raising complexity on Scrum.Org > It is all about the stakeholders and creating value (with EBM):
But the thing that's missing: How to become this things into the backlog to prioritize them? In my practical experience often those "non-customer-related" topics are hidden work. Especially when they are new/innovative and not yet part of the DoD.
It would be helpful for the practice if, with regard to the backlog, the variety of topics in relation to value (EBM) could be pointed out again.