Excessive focus on the development team
I dug up the first official version of the 2010 Guide to Scrum. I wanted to learn more about the first iteration of Scrum as a framework. How was it initially designed? I knew that in the beginning, the role of the Scrum Master was very different than it is today and I wanted to learn more about that. But that’s not what struck me most. In the current 2017 Scrum guide, it’s still noticeable, but it doesn’t get as much attention anymore. However, I think it’s still a fundamental part of the Scrum structure and I see a lot of challenges with it. What is that? One thing: the obsessive focus on a development team.
Scrum for devs, not for the business
It is important to mention a Scrum Master role in the context of the first Scrum Guide. In 2010, the SM was standing way closer to the Development Team than to a Product Owner. The role did not provide symmetry between the interests of the Development Team and the PO. Scrum Master was like Frodo Baggins sent by the Development Team to the business side to ensure proper understanding of the Scrum framework and to teach an approach that the Development Team perceived as convenient and not disruptive. The Scrum Master was responsible for identifying a potential Product Owner and for tutoring him or her on a set of Scrum events, artifacts, and roles. If the Scrum Master failed to do that — the Scrum Team didn’t have the Product Owner or the PO wasn’t fully taught for the role — they were held accountable. The Product Owner was therefore a rather passive participant in the Scrum approach, adjusting their behavior to the needs and requirements of the Development Team.
The ScrumMaster works with the customers and management to identify and instantiate a Product Owner. The ScrumMaster teaches the Product Owner how to do his or her job, to optimize the value of the use of Scrum. If they don’t, the ScrumMaster is held accountable.
Scrum Guide, 2010
I can imagine that. The Development Team had some work to do. Therefore, with the help of the Scrum Master, the team subordinated all possible business circumstances to the team’s needs. What amazes me is the impression that the main focus of the Scrum Team at the beginning wasn’t the product itself but the comfort and tranquility of the Development Team. The PO was at the team’s disposal and performed functions that served the Development Team. I don’t know if that was the intention but when I read it now, I understand it like that. Maybe it looks like that because the IT guys created it. Scrum was an IT framework (a controlled environment) that the business client was pressed into — to make the programmers’ lives easier. The business has been just an incubator, an addition, and an accessory, a guest, not a co-creator. Interesting.
Tricky semantics
A not particularly complex semantic analysis of the 2010 version of the Scrum Guide confirms all that. For almost 60 uses of the words “The Team” we find half as many instances of “Product Owner” and “Scrum Master”. Verbs used in the Guide next to the “Product Owner” and the “Development Team” roles prove who was playing the first fiddle.
The Team: can change, add, modify, plan, perform, identify, manage, make a review, have a meeting, have in mind, self-organize, invite, determine, start, build, optimize, group, do the work, be committed, meet, talk, have the final say, revise, mean, figure out, can assess, collaborate, select, work, have a tolerance. Termination of the sprint has been usually TRAUMATIC to the Development Team. It sounds like a reference to something active, participating, and responsive to the surrounding — a living organism.
In the meantime, the Product Owner is „officially responsible”. This is the person who: maintains, ensures, clarifies, manages, and controls Product Backlog, keeps the list updated, presents if needed, and is available. PO must also understand that the Development Team may not have yet been able to include everything required for implementation in their Definition of Done. PO should also understand the Definition of Undone. If they are not ready, the PO should understand it and say nothing, for the sake of the Team’s comfort. It sounds like extreme objectification.
I have to admit that in the current 2017 version of the Scrum Guide, both PO and SM are two mature roles with autonomy, having more freedom, respect, accountability, and space. But Scrum still focuses primarily on the Development Team. The Guide expands almost exclusively in one direction.
We, you, and your Scrum
Scrum started as a framework focused mainly on the Development Team and, in my opinion, it's still facing its consequences of it. It is not naturally friendly to the business. It does not support the business enough, although it already considers it to a greater extent than it had a decade ago. Therefore, I have the impression that on the business side it is often treated neglectfully.
Since Scrum is the banner of Agile on the business side, the whole concept of agile thinking often backfired. “We have Scrum Masters, we are agile because IT wants us to do it that way. Leave us alone“. This may be due to the belief that Scrum is purely a technical framework. It is something that IT does to business. After all, Scrum Masters are largely hired in IT. I know managers who say to their SMs: “You are from IT, work with the Development Team, not with the business”. But I hope that I will hear it less and less often.
The above goes back a decade. But last year’s Scrum Master Trends report shows that in 2019 Scrum was still considered a framework imposed on business by the IT side. Even though it should be an agile way for both IT and business to work hand in hand on a PRODUCT DEVELOPMENT.
Why is that? Is it because Scrum marketing was not thoughtful enough? We all know that the framework should be a helpful tool for the whole Scrum Team and organization for the sake of developing a valid product or service that brings value quickly and often. And that the Scrum Master should support the Development Team, the Product Owner, and the organization. Still, Scrum leans out of the window and waves to the client from an IT basement filled with cardboard, servers, and defective furniture.
What should be done to change it?
The original Polish blog post: zwinnemysli.pl
