Avoid Immutable Pieces
From the Scrum Guide: “Scrum’s roles, events, artifacts, and rules are immutable”
Although Scrum pretty much works well as a framework for the contexts in which it was developed, there is no one size fits all framework. The challenge with immutable pieces is what if you need to change one, not because you don’t understand it, but because Scrum doesn’t exactly fit your situation?
Scrum tells you to remove impediments, but impediments to what? The only real measure it gives you is to be following Scrum. How can you tell if you’re making an improvement or not? An understanding of the theory of Lean Flow can help you determine if a projected change will be a good thing or not. We have created a qualitative measure called the value stream impedance scorecard (VSIS). We all pretty much know if you go into a place whether it’s going to be a good place to work or not. The VSIS essentially takes what we intuitively know and makes it explicit. By lowering the resistance the VSIS scores, we can improve our forward progress.
If you have a choice between action A or action B you can usually tell which will be better by the effect each should have on the VSIS. If you’re not sure, just run an experiment to see.
Software is not the same as the physical world. While work in the physical world is often visible, in the software world it often isn’t. Consider how you can see what’s being built in the physical world, but in the software world, writing bugs or good code looks the same.
On the other hand, the software world has some advantage. For example, you can design software on top of a foundation that is readily changeable. You can also build a piece of software and start using it while in the physical world we often have to create prototypes to see what itll look like. It also takes more time to move from one task to another in the physical. Once you start to think about it, there are quite a few other differences.
Having a framework that is specialized for software can be designed to fill in what the physical world automatically provides for us but the software world doesn’t. It also allows for us to create value faster than would be possible in the physical world.
Creating and marketing generalized frameworks may be advantageous for those marketing and supporting them, but if you’re doing software, you want a framework designed for software.
While Scrum tells us we should fill it in with needed practices, it leaves us to figure out what some of these are. Agile Product Management (APM) is one of the key pieces not included in the Scrum Framework. With rare exceptions, we think APM is advisable for all software teams to be using. Other concepts including explicit workflows, making all work visible, managing work in process having definition of ready and definition of done are also virtually ubiquitous. But even if they aren’t, an experienced instructor will talk to the leadership of any team they are going to be doing training for and will know when to leave those out.
There is no reason for teams to have to reinvent the wheel. Scrum should be thought of as an example of what to do while being given the core practices that the team will need. Given the long history of teams new to Scrum having pretty much the same challenges, there is no reason not to anticipate them and provide what will virtually certainly be needed.