Choosing a non-scrum method
I've returned to scrum.org after having completed my PSM1 and PSPO1 some time ago. I'm currently looking toward my PAL1 exam.
I do a lot of work in government where we deal as is often the case with scrumerfall or some form of hybrid. I was reading this blog:
Why you Need Only ONE Product Owner
It has this quote:
Limit the planning horizon to no more than 2 to 3 sprints of work ahead, as preparing more work is likely to result in waste. If you are able to predictably specify your work more than 3 sprints ahead you maybe should not be doing Scrum as your product is not complex enough.
I've been working on quite a few projects that fit that: we are deploying a COTS product which simply needs the sponsor to define what we are doing over a series of iterations, but from the implmentation perspective "it isn't complex it's at worse complicated." (Often of course, customers have a different view but if you've implemented the same thing - or competing equivalents of an identical thing - you see the standardisations in the complexity).
So I'm wondering: how do i drive the conversation that "actually, we don't need scrum - we can work iteratively without imposing the organisational change required to get value out of Scrum"?
Scrum doesn't just describe the roles, events, artifacts and rules that make up the framework. It is also the language of change, in so far as it describes what organizations don't currently do, or condescend to do only in emergencies when empiricism is most desperately needed.
I'd suggest that if you divorce Scrum from the language and expectation of organizational change, the result will not be Scrum, and the outcomes expected of the framework will not then be obtained. This isn't to say that such an approach would be wrong, but the outcomes would be different.
Scrum is a set of values and rules. To demonstrate that Scrum may not be valuable, I'd find places where it doesn't make sense to follow the rules.
In the particular example of deploying a COTS product, yes, you may be able to do the work iteratively and/or incrementally (depending on how you lay it out). But do all of the things associated with Scrum make sense?
Does it make sense to have fixed timeboxes for each increment of work? If you can plan a schedule of known work, can you effectively make equal timeboxes? Or might it be more beneficial to have timeboxes of various lengths for different steps in the process?
Do you need to perform Product Backlog Refinement if your work can be fully scoped out in advance? Perhaps you may discover nuances in your current environment that require plan adjustments, but perhaps not full-blown refinement every iteration, especially if the known work hasn't changed.
Do you need to perform a Sprint Retrospective after each iteration? If you have an overall plan and your plan is holding true after the iteration, does a retrospective add value? Perhaps it would be useful to do it if there were significant deviations from plan to perform a retrospective and perhaps a replanning activity, but perhaps not after every timebox.
If the organization understands that Scrum contains certain rules and not following the rules results in something that is not Scrum, then finding reasons why it doesn't make sense to follow the rules and therefore doesn't make sense to implement Scrum should be a straightforward exercise.
Instead of implementing Scrum, you can look at good practices and use the ones that are valuable. Perhaps something like a Daily Scrum is still useful to have early insight into schedule deviations. Perhaps just-in-time retrospectives and replanning activities would be useful to respond to unexpected events. Perhaps having a dedicated Product Owner makes sense to help ensure that the effort keeps the right focus. But implementing these individual practices is not Scrum.
I've found it difficult to hold up the Agile Manifesto or the Scrum Guide and get people to buy-in to what I believe in. Often times, the developers just want to code, the stakeholders just want to get work done, the sponsors just want to avoid sunk-cost and the customer just wants a product that works. They don't care about the underlying business process.
Gradually, I've shifted from making the process (Scrum, Kanban, etc.) work for everybody, to making the best product that is developed using a good, common-sense approach. For instance, if two developers need to discuss something for the day, I don't see the value in having eight or more developers stand or sit around for 15-30 minutes and listen. I take a pragmatic approach with Agile. After all, I'm not selling Agile to customers. I'm selling a product that makes the customer happy, makes business profitable and keeps me employed.