The need to understand the principles that drive your practices

Most people want to know what they should do. There is an attraction for starting with practices. And frameworks typically indulge in this by spending much of their time on practices. Even when principles are discussed, they are presented as guidance on what to do.  But it is also important to understand why those principles are good guidance. I sometimes refer to this aspect of a principle as a law – it’s the behavior of things to which principles apply.

There is a significant difference between principles and practices. Many in the Agile community believe it is important to start with practices. That people need to follow the practices, such as Scrum’s practice of time-boxing called Sprints, without necessarily understanding why they work. That after doing so for long enough  Even when principles are discussed in most courses they are mentioned as “here they are” instead of,

The justification for this is that people need to understand how to use these practices before going beyond them. There is truth to this if people don’t understand the principles lying underneath them. But people can readily understand principles of Flow and Lean because they’ve been at the effect of them their entire career. What we don’t need them to do is to re-invent solutions to challenges based on these. Frameworks that give you solutions without Flow and Lean principles to use in a pragmatic way lock you into them.

I have observed that while people need a set starting point they also need to understand why things are working. This creates learning opportunities from the start and enables a gradual improvement, or even, transcendence of the practice.

The martial arts model of “Shu (follow) Ha (break with) Ri (transcend)” is often used to justify this approach. But there are several flaws in this logic. In the martial arts you are trying disengage your mind at first, not so in knowledge work In addition, no guidance on how to move from following (“Shu”) to breaking with (“Ha”) is provided. What’s worse, is that by defining Scrumbut in the way it has been, the belief that people who don’t “follow the rules” are somehow bad and get poor results.

The worst flaw, however, is more insidious. It’s the loss of the opportunity to learn while using. This would be to provide the underlying model of the practice. People can ‘follow’ the practice while seeing how it applies the underlying principles involved. This enables them to learn how to use these principles and tailor the practices for their own situation. They never break with the underlying principle but will break with the practice and possibly even transcend it completely. But not the principle.

Let me give you an example from sailing. Fledgling sailors are told to look at a flag or ribbon on the mast to see which direction the wind is going. But they are also told that they can learn to see the wind in the water if they look upwind and attend to the ripples on the waves. Newbies can immediately use the flag on the mast. But by looking at the more advanced practice of looking at the ripples on the waves they can learn to see the wind before it hits the sail – a very useful thing. So very quickly they learn to see the wind as it hits the sail and before it hits the sail. In addition, they eventually notice side ripples on the main ripples. These are from swirls in the wind. This tells them even more. They learn through a combination of using the basic practice, trying more expert practices, falling back to the basic one when needed and understanding what is happening much more. They never transcend the principles – only the practice that they started with. And they don’t have to do a sudden “break” with the practice, but can do it over time.

Learning with this combination of practices and principles is what sets Net Objectives training as different from frameworks. All frameworks are a combination of practices and principles. But the framework is defined by some core set of practices (e.g., in Scrum you must have timeboxing and cross-functional teams). The dangers of this are twofold. The most obvious one is that the practices prescribed may not fit your organization. But the other, more insidious one, is that doing this prevents you from learning as quickly as you would otherwise.