Principle Based Agile/Scrum Adoption

I’m a pragmatist.  I need things to make sense. So, when something like principles are introduced to me, I start to ponder questions like… What is a principle? Where did these principles come from? Are all these really principles? How do these principles relate to each other? Why should I care? Etc. Yep, I can get myself tied up into a knot thinking about all that. However, in that thinking I can find a nugget of learning.  (While other times, I capitulate and get a beer.)

I’ve done a huge amount of thinking about principles.  Relative to many of the questions above, I’m still drinking…thinking. However, I have thought AND experienced a lot about applying principles and values in my Agile coaching and training.

The word principle comes from the Latin for ‘source’ and ‘foundation’. The definition of principle is “a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning…a fundamental source of basis of something”.

Principles are discovered.  They are the underlying understanding of why things happen; how things work. 

As I coach and trainer, I also focus on the Scrum Values: Commitment, Focus, Respect, Openness, Courage.  Values are another interesting thing (yep, more thinking on my part, and more beer).  Interestingly, a definition of value is “a person’s principles or standards of behavior; one’s judgement of what is important in life.”  Principle is used in the definition of value!  It stands to reason then that values are also foundational. (I was quite thrilled to see the addition of the Scrum Values to the Scrum Guide!)

I consider the Lean and Agile Principles as the way we approach the work, while the Scrum Values are the way we approach each other as well.

We often don’t realize why we do the things we do. By ‘do’, I mean performing some action in response to, or in the development something. Usually we do things because it worked in the past. Often, we do things because that’s how we were told to do it; the infamous ‘the process says…’

It’s easy when you just know what to do or are told what to do, and things just work. As an Agile coach, it’s not uncommon for people to ask me what to do. I push back on those questions, and ask “what are you thinking, and why”.

The action to take is no longer obvious, or doesn’t work, because something has happened or changed. We need to do something different. But what?  And if we did get an ‘answer’ from somewhere else, would it be relevant to our current situation; our current context? I’d suggest by understanding and applying principles and values we can figure out what to do given our current context?  Let me offer one of my favorite Scrum examples.

From the Scrum Guide: “Product Backlog items…for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box”.  The activity to get the items in the backlog ready typically happens with Backlog Refinement.  Sounds good.  However, what if NO backlog item is ready What’s about to happen?

My guess is that the Sprint Planning meeting is at least going to be a tough one. We might not have even one item ready to commit to within the planning time box. Strictly speaking we can’t, and I’d argue shouldn’t, commit to anything. That would be a violation of the Commitment value. However, things are about to come to a screeching halt. We won’t be developing in the next sprint as many items as we might otherwise have done.

Now let’s look through the lens of principles and values. In Agile, the principle of creating value is always top of mind.  Frankly, the key aspect of Lean thinking is Value is everything, and all else is waste. Arguably (i.e. one could chose other principles) another principle at play is flow also known as ‘Mura’; the steady, continuous stream of activity in the creation of value. In our case, flow my friends, is disrupted affecting the creation of value.  The lack of flow, and probably a total stoppage of any creation of value is now at hand and is waste.

If we valued flow, then what would we do? (By the way, there is no Scrum process document that tells us what to do. Remember, Scrum is a framework.) When we keep flow in mind, we could come up with all sorts of solutions for ourselves, AND it would be for our context.  That’s why Scrum is a framework and not a defined process, and why we rely on self-organizing teams to think. As a team, we’d figure out how to re-establish flow, or at least get the best flow possible, and by consequence some creation of value.  Armed with principle thinking we can determine for ourselves what to do.

For example, we could stop working on the lowest current Sprint Backlog item, miss our sprint commitment, and use the time freed up to get something refined at the top of the backlog. Yep, forgo the sprint commitment in favor of keeping some amount of flow and value creation going. At least that way we’d have some flow in the creation of value in the next sprint, and maybe when we plan that next sprint we should be allocating more time to get ahead on backlog refinement.

There are certainly other solutions.  What I know is that when teams honor and apply principles & values as the foundation to their solution, this enables smart people to figure out for themselves, given their current context, what to do!  Magic happens.

Additionally, as a result of deciding for ourselves what to do, we learn which is yet another principle: exploiting knowledge.  I just love a reinforcing system!

Here’s my second favorite example.

We’ve been having retrospectives for months and we’re now bored with the whole thing. Who wants to hear another litany of stop, start, continue? The Scrum Master has been trying to make the meeting more fun; however, the things he/she asks us to do seem dumb. So, we decide to stop having a retrospective, perhaps agreeing to do one as needed to appease the process police and our Scrum Master.

This example might be more obvious. A principle clearly at play is exploiting knowledge; to constantly learn and apply that learning. The retrospective is one place where we take the time to exercise that principle.

I’d argue there is also a Scrum value at play, Focus.  I’d argue that the retrospective is a focused time for exploiting knowledge.  It enables team level mindfulness. If we stop having a retrospective we’d lose those foundational aspects of the meeting relative to the principles and values. Instead, we might focus instead on how WE can make the retrospective more meaningful.  What can we learn, and what can we do? Perhaps we’ve lost focus on the ‘experience’ of the sprint, and should refocus our attention to the Scrum Values?

Now all this might seem ‘duh’.  I’d ask you though; why do we see so many poor manifestations of Agile and Scrum?  Could it be that we focus on the admittedly simple framework of Scrum?  Perhaps we lose or fail to keep focus on the foundational principle thinking behind that framework? Without the foundational principles of Agile/Scrum, we are unable to think for ourselves.  Without the values of Scrum, we lose the human principles.

When I train Agile/Scrum to teams I, and my Agile For All colleagues, spend better than half the time on the Lean and Agile Principles, and Scrum Values.  Even as we introduce the Scrum framework, I relate back to those principles & values. Your problem is in your context and is therefore yours, and there is no way anyone can possible think of and provide for every potential future challenge.  You need the foundational thinking as a source for deciding what to do.  We teach people how to think!