Long weekend musing on Scrum
July 05, 2020
Did you like the punny title?
Unfolding of events
June 30, 2020 - evening:
Jason : Have you read the blog from Stack Overflow about Scrum? There are so many things that triggered me.
Jill’s Brain: It’s almost bed time, I don’t want to think hard. I have a play date with Jacob (the nephew) tomorrow and would love to have a good night’s rest before then. What to do…
Jill: Honey, I don’t want to read the post tonight. Since we are going to the land far far away (Toronto to Whitby), I can read while we are driving to Jacob’s. At least if I am triggered, I will have a great, fun time with Jacob and the fun will balance out the stress.
And we went to bed happy.
July 1, 2020 - on the journey to the land far far away:
Jill reads the article aloud, finishes, and is relieved that the article was not as stress inducing as was anticipated based on the warning the night before.
And so, Jason and Jill had a great discussion for the rest of the trip and enjoyed the fun times with family.
The commentary
Good developers versus average developers
The post opens with:
A question on Stack Overflow’s Software Engineering site… tries to come to terms with the impact of scrum on developers’ ability to do a great job. The claim is a bold one: Scrum is turning good developers into average ones.
Right from the start, the claim of “turning good developers into average ones” stood out to me. However, I pressed on and read the rest of the article to give it chance to reveal the arguments. I was disappointed to find a lack of supporting pieces to make this claim stand.
For example, I was looking for their definition of “good developers” to help me level with their view of the world. Instead, I am left with my own interpretation of good developers. I know from experience that finding this definition is elusive. Some developers think that a good developer is someone who writes really great code, documents every piece of the system, has 100% test coverage of the system, etc. Others may define it by different metrics, such as documenting only the most important pieces, writing fast, high value tests, etc. I certainly have met developers who are very uncomfortable with fast moving customer requirements, so they halt the pipeline and force the organization to provide them with well defined requirements. Some organizations value this approach, and these developers could be deemed as great developers in those settings. But place the same developer in other organizations, and they will probably be thought of as the opposite.
So, when we lack a shared understanding of what a “good developer” is within the context of the article, it is hard for me to connect some of the arguments back to the initial claim.
Using empathy
But, maybe I am nit-picking. Let me try to put myself in their shoes.
This is actually not hard to do. I’ve seen and experienced manifestations of each of the pitfalls listed in the article. So many organizations have “adopted” Agile and Scrum but completely missed the point. In my opinion, each of the pitfalls is a manifestation of problems that are bigger than Scrum.
I want to address each of the pitfalls in future posts as I want to group some of them together to address higher level themes. For example, Very productive individuals that don’t work as a team, and No time for cross pollinating or exchange with peers both point to the same issue: not understanding that Scrum is all about the team.
I am convinced that each the pitfalls stems from not undestanding the core of Agile and Scrum.
Education
So let’s start with basics. I think it is important that everyone who is practicing or wanting to practice Scrum or any process sharing its Agile roots needs to read up and internalize:
Since the topic of this blog is Scrum, I will focus more on Scrum Guide.
The Scrum Guide
After more than four years of practicing Scrum, I must confess that I have never actually read the Scrum Guide until few days ago. I have gone through Scrum Master training in the past, and read hundreds of pages of books about Scrum and how to practice it, but never the 19 page guide. So bizarre when I think about it.
I have now, and I am happy I read it. While I am pretty confident on how I practice Scrum, the guide definitely made me reflect on things that I could be improving in the future. For example, for Sprint Review, in my work there is a lot of emphasis on demo but not so much on other areas. We could definitely improve on:
- Product Owner explaining what Product Backlog items have been and not been done
- Review of how the marketplace or potential use of the product might have changed what is
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product
- and many more
Those product update discussions happen, but often outside of Sprint Review. Attendees of the meeting to brief stakeholders of product backlog items often do not include the development team. In my ideal world, this is a missed opportunity for the development team to really feel included in the discussions and opportunities for learning and not just “a group of people who executes whatever the business wants”.
Practicing Scrum using Scrum Guide
I had a long discussion with my husband on this matter. The question that continues to linger in my head is: is the Scrum Guide enough that when a team wanting to adopt Scrum reads it, they will be set up for success?
Before answering this question, what are my takeaways from the guide?
In my view, The Scrum Guide is very clear on fundamentals of adopting the framework. My key takeaways are:
- Scrum is about empirical process. Maximize the amount of experiments that helps you learn and clarify the view of your world or your niche. Shorten that feedback loop.
- Embrace the three pillars of empirical process control: Transparency, Inspection, Adaption. It really just boils down to these three. Rinse and repeat.
- For Scrum to be effective, the team should be capable and embrace the Scrum values: commitment, courage, focus, openness and respect.
Those are the core in my view. The rest of the guide simply gives us a framework on how to set up the way we work to optimize for learning and applying ourselves. I put less emphasis on the latter parts of the document because this is I think where I did not agree completely with my husband. He argues that it’s enough for the guide to describe the rituals and how they support the empirical process. However, in my view it did not go deep enough to help a team use Scrum from ground zero.
Personally, I was lucky that I went through the training, and read books about it, but Scrum Guide alone in my view is insufficient. Jason argues that this is where practice fills that missing piece: real-world application of Transparency, Inspection and Adaption. In his view, upon recognizing that they lack strategy or plan to apply Scrum, a team that is actively applying the Scrum values will self organize to adjust their workflow, identifying the missing pieces along the way. By using the ceremonies to support the values, they should be able to derive a workflow that helps them improve. I think this view is a bit idealistic. I argued that the guide already went to the trouble of explaining the rituals and key elements of the rituals, and so could have been a bit more generous with describing how the framework is applied in practice.
Growing together
Right after reading the Stack Overflow post, I was so ready to just write about how people are just doing things wrong. But after trying to read a bit more on the basic resources of Scrum, I was left dissatisfied.
When I was younger, I expected everyone to just be awesome. I often find myself in a room where everyone agrees that doing X is the right thing to do. My younger self would take this validation as an indication that people will just do the right thing from this point on. I am often disappointed when the good things don’t happen as I expected them to. As I get older, I learn that there are times that people do believe doing X is the right thing to do, but they just don’t know where to start. Turns out, people need time to be awesome, and if you are willing to help them get there, the investment is always worth it.
I think the Scrum Guide could have helped people wanting to adopt Scrum a bit more. But then again, maybe I should have just fished around for more resources. Perhaps wading through a gazillion articles on the web would have given me what I was looking for.
Beyond a “how-to” guide, in my view, it takes a lot more thought and experience for people to adopt Scrum. This is really where a Scrum Master or experienced Scrum practitioner (legit ones) can help people struggling with adopting the framework or just starting their journey.
I am thankful for many people I have worked with that solidified my understanding of Scrum. To this date, I am a firm believer of the framework. The Scrum Guide may be incomplete, but it is a good primer to Scrum in my view. However, there is still a big gap that needs to be filled which I hope to share in my next post - “A way to Scrum”.