Well, a little over a week ago, Schwaber and Sutherland released the Scrum Guide 2020 and it introduced some changes and new concepts, including
- Reduced prescriptive guidance
- One Team One Product
- Introduction of Product Goals and Sprint Goals
- Self Managing over Self Organizing
- "Why" added to sprint planning topics of "What" and "How"
- Language simplification
I'm interested in people's thoughts on these changes, both within the orthodox Scrum methodology, as well as how its applied by Atlassian. The following was captured from discussions with stakeholders in my organization regarding my initial assessments, so its just opinion. I am a senior architect and strategy leader at an international financial organization, and I've been a scrum master for 17 years.
In respect to Product Goals, I agree with the principle, but both Schwaber and Sutherland, while having the goal of 'enabling business agility at scale across an entire organization', simply don't deliver, and instead provide a product-centric lens through which to view this agility, which I believe both devalues what can be offered, and is misleading to those who just blindly follow dogma. On the one hand, I'm happy to see, after 25 years, for them to come to realize that alignment with greater goals and getting to the 'why' is important, and yes, its a move forward, but I would argue that they've still missed the mark. While I can get behind 'The product owner is responsible for making sure that the Product Backlog has a goal that the team understands, is excited about it and commits to it — and the whole team are moving together towards it.', this is team alignment with the product owner's goal, with nothing about clarity and alignment around higher level goals and who that product owner in turn delivers to. It also implies that a product goal is static and can be completed. And I appreciate the problem they have, in that Scrum is to some extent a bottom-up self-actualizing model with the only top-down in the model coming from the product owner, so top-down alignment is already a challenge.
It doesn't give people 'below' the product owner the big picture of what they are aligning to and why. But on the other hand, a *good* product owner should be able to encapsulate and express this in the scope of the team and their domain of work, so a Product Goal can do this. One of the big downfalls of Scrum that I've encountered over the years has been that certain personalities are task-oriented, and simply want to complete an item, which ends up causing problems if there isn't a complete and accurate set of tasks defined to fulfill a goal. This approach of adding a Product Goal at least shifts the thinking to focus on what outcome is desired instead of on the list of tasks to be completed, and I like that. The practical downsides though are (a) you need a good product owner who can define a goal well, and that could be challenging, (b), this guide proposes that the goal belongs in the Backlog as a grouping mechanism, which is good in theory, but when you have tools like Jira for scrum management, then it will be a bit puzzling how to realize this. As well, this is complicated by the program management needs across multiple teams within the same product line (the basic premise is One Team One Product, but that isn't realistic for many large enterprises, and is even more questionable when teams are in fact microservice focused). I think it could be implemented, but you might end up violating SAFe portfolio/program management principles to make Scrum work; whoever sets the Program Epic at the program level could effectively define a common goal for all teams working on the Program Epic, but then no team could effectively achieve the goal on their own. So instead move the goal back down to the team and scope it to the team. Teams lose sight of the overall goal with only a few people focused on the actual goal above the team level, but this may still be of value for alignment.
Pragmatically I'm puzzled about how to implement; Perhaps using tags in Jira to group backlog into goals could work, but clear visibility and reminders of the goal would be missing. I'm curious how Atlassian will address this, as they too must respect both Scrum (Jira) and SAFe (Advanced Roadmaps and Jira Align), my guess is that they'll implement purely in Jira, not add a new level to backlogs for goals (basic architectural problem with using Jira are the hierarchy limits), but might implement some way to have a new goal element (perhaps based on tags) with UI integration at the backlog and backlog item levels. This of course doesn't solve how to implement Sprint Goals, but that might be done through the Sprint Definition mechanism, and I suspect might actually be easier (Schwaber and Sutherland specifically call out that the product goal belongs in the backlog, and that the rest of the backlog relates to that, defining what will fulfill the product goal).
I also note that Definition of Done does not touch on the either the Product or Sprint Goal, yet the Product Goal is the long term objective, and the Sprint Goal is the goal of the sprint. In a worst case, it seems teams might be put back in the position of not knowing when they've successfully completed a sprint.
So, I think its an improvement, but is not a cure-all, and the goal of enabling business agility at scale across an entire organization remains elusive, especially for medium-large organizations. It is incredibly important that information flow freely, and that alignment with enterprise goals is maintained, especially in fast growth and large organizations, so being able to provide the "whys" of things is more critical than ever these days. So these changes help, but they change very little about how i solve the fundamental problems of communication and alignment. That position will be different for everyone and be related to the size and maturity of their organization, so I know this change will work for some, perhaps many. What do you think of the new changes?
