There is a tension between the need for adapting a known and proven collaboration framework, and the need for said framework to be allowed to do its job.
I have during my ten years of agile, the last five years as a full time mentor and coach, seen countless of "Scrum" implementations where they had removed everything they found difficult and hard, and therefore didn't achieve what they wanted to achieve.
On the other hand: I have also seen numerous agile collaborations where they applied just the tools they needed at the time, tools that also can be found in different frameworks such as Scrum, but together with other tools and ways of working. And it has been working just fine.
I have during these same years only seen Scrum being run by the book (The Scrum Guide) once. Most of my clients work in environments where the implicit preconditions of Scrum doesn't really apply. So they have to adapt in order to get work done.
Adaptions of Scrum are sometimes called "Scrum Buts" since they are described with the words "We work with Scrum, but...". I think that's appropriate for cases where the organization takes away the things that drive good change and thus never achieves what they have set out to achieve.
I suggest the term "Scrum Ands" for the cases where your situation calls for a slightly different set of tools than what is provided in the Scrum Guide. For when you inspect and adapt the framework, in a way that gives you better outcome than the alternative.
The result of your toolset hacking will not be Scrum, of course. Scrum is defined in the Scrum Guide. Any deviations might be useful, but it will not be Scrum.
However, since Scrum contains most of the elements you need in order to make your collaborations more agile (organizational capability to prioritize, collaborate on value creation in self organizing teams, daily synchronization between people, clarity on what is ready for implementation and what is done, continuous improvement etc.), and since the framework is pretty well known, it can be a good idea to present your ways of working as your own twists to Scrum.
I call them Scrum Hacks. Distinct ways of collaborating that replace or complements existing ways of working in the framework. Like the idea of having retrospectives either more frequent or less frequent than each sprint. Or the idea to plan only one week at a time. Or having an ongoing Scrum meeting in digital channels instead of the daily fifteen minutes standing in front of the sprint backlog.
As soon as you start experimenting with Scrum Hacks, the result isn't Scrum. It can make your outcome worse. But it can also make it better. Reflect on why, and share your favorite hacks with your friends in the community. Let's build a catalog of proven Scrum Hacks that explains under what circumstances they have improved our lives.
What do you think?
Inga kommentarer:
Skicka en kommentar