Can Scrum be practiced in a non-product environment?
I've been closely observing how the leadership in large organizations have been forcing the use of Scrum but aren't really willing to listen to Scrum Master's or to employees at the lower level. As a consequence of this, many people are re-arranged to form new teams as part of an Agile Transformation but in many/most cases, the teams have no alignment to their end product. They tend to be aligned towards completing work for multiple projects.
Scrum events are forced upon these teams, they are asked to vertically slice work, but the work cannot be sliced. Everyone complains that this is reality but no one seems to remember that their purpose is an "Agile Transformation" and that this may require re-aligning how they see or do work. Agility is often seen as reducing the amount of time taken to do work.
I'd consider the above a dysfunctional overall effort (please feel free to correct me if I am wrong). In such a scenario, can Scrum still be successful?
What I've seen is that teams don't often create Sprint Goals in such scenarios and if they do, then they don't have a single unified Sprint Goal. Instead, they have multiple Goals for that Sprint, often small and in an order of importance. The Teams are able to align and focus around these and on occasions are able to meet these goals. The teams are not entirely cross functional and have dependencies with other teams or with Waterfall projects or timelines.
So, two questions:
1. If the team is able to deliver potentially releasable increments, then is the use of multiple Sprint Goals okay?
2. Does it make sense for teams to use Scrum when the problems that surface as a result are often ignored?
To your point....I think team's can still have success, however, they won't be able to realize the full potential the Scrum Framework could give them and the organization (people tend to find ways to make the best of the dysfunction).
Scrum should make transparent the difficulties the teams have a result of improper alignment around products and stretching team members across multiple projects. If leadership is not willing to take this evidence into consideration it can leave team's with little choice but to have multiple Sprint Goals (or perhaps primary and secondary goals).
My take on your questions in this particular context is as followed:
1) I think it's okay if it allows the team to best deliver the work in the current situation. As the Scrum Master I'd be working with the team and organization to continue to find ways to change the status quo based on evidence gathered as a result of delivering on multiple projects and goals.
2) I think it still makes sense given there are still people pushing for change as a result of the challenges that doing Scrum is making transparent. The Scrum Framework is working, however, the currently organizational patterns are working against further success with it.
In such a scenario, can Scrum still be successful?
If Scrum helped to make the issues you refer to more transparent, would that be a kind of success?
If Scrum helped to make the issues you refer to more transparent, would that be a kind of success?
Ian Mitchell, Yes, the dysfunctions are evident, and in that perspective Scrum is successful, but more often Scrum is made to work around the problems than actually change the existing landscape. Hence you hear things like, you can't always go by the book (scrum guide), there is reality and then there is theory or we can't always achieve what scrum is asking.
How far does transparency extend? If the benefits of using Scrum failed to materialize because of the issues you refer to, would people be surprised?
1. If the team is able to deliver potentially releasable increments, then is the use of multiple Sprint Goals okay?
I have seen Scrum applied in a team of 3.5 where they weren't producing increments, but were using Scrum to make their transactional work (Customer Service) visible and be able to deliver superior service to their customers.
2. Does it make sense for teams to use Scrum when the problems that surface as a result are often ignored?
I can assure you that in a company that is profitable, at some point, somebody will take notice. Until then, if Scrum is helping teams collaborate, work efficiently, be transparent and produce superior products, services and experiences, then they should continue down the path of agility.
At the end of the day, if all I can do is inspire one team to transform themselves through the knowledge of Scrum, I would consider that a success. Even if they're not producing done increments or adhering to all events and artifacts.
Executive leadership has transparency into the current state. Whether they truly understand the need to find better ways to align their workforce towards a product mindset is debatable. Also, the very fact that there is existing work that cannot come to a halt makes the change rather slow.
Even if they're not producing done increments or adhering to all events and artifacts.
@Mark Adams, I don't disagree with the results that may be achieved and the good intentions that come out of that practice you mention above. The point you made resonates with what I was reflecting upon. However, would the true benefits of Scrum be fully be appreciated or recognized if teams don't produce "Done" Increments or the teams are not taught to strive towards producing "Done" Increments? Also, if we encourage that there is no need to adhere to events and artifacts, would the resulting practice be Scrum?
I believe the answer is mentioned quite clearly in the Scrum Guide:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
There are always benefits that result from adopting "parts" of Scrum. Sometimes, organizations decide that "some" Scrum provides enough benefit while still preserving some of their existing non-Scrum practices and behavior.
However, in my opinion, the practice of Scrum in all of its roles, events, artifacts, and rules is transcendent.