The Agile Rabbi - First Sermon - The Three Pillars

Because one of my passions is understanding team development, helping teams to grow, be more efficient and to better understand and implement Scrum I have a friend that calls me the Agile Rabbi. To me this brings to mind a very interesting image of a rabbi. Take your typical rabbi, you decide what that looks like, add a Dr. Who scarf from the Tom Baker days as my prayer shawl (I wear a scarf like that in the cold winter months).
The Agile Rabbi - (c) Noah Brody 2018

 I have certificates from both Scrum.org and the Scrum Alliance and I have been practicing and mentoring people in the ways of Scrum for over 10 years. So I do have a background in agility, specifically Scrum. I am not a rabbi and not able to give rulings on religious matters, Scrum isn't a religion, although I have seen people try to implement it as one.

So let me take a few minutes for of your time, not long - I don't want you falling asleep during my first sermon, so I will try to keep it short. (It is appropriate for you to politely laugh at my poor attempts at humor. I am not sure if falling asleep during a sermon or a short sermon is the part you may want to chuckle at.)  I have heard too many times that people do (fill in the blank) because Scrum says they have to, or because a Scrum coach or trainer told them they have to. Think for yourselves people! As a Rabbi that I looked up to when he was alive, Rabbi Moshe Kushner (z"l) would say (translated from Hebrew) "use your head before your hands". To paraphrase, we need to make sure we understand and think before we do. 

While the Scrum meetings are often called ceremonies that should not give them a religious connotation. Each Scrum meeting serves a specific purpose and it is important that all attendees understand that purpose and what is expected of them. When people don't understand what the focus of the meeting is and what they should be accomplishing the meeting often becomes a waste of their time.

Scrum is about many things, high on that list are focus, communication and feedback loops. As it says in the Scrum Guide "Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation." Everything we do in scrum must relate to one or more of these pillars. If you do something that you cannot relate back to one or more of the three pillars, then you aren't doing it because of Scrum. You may be doing it for corporate reasons, which are also important. (At least they are if you want to stay gainfully employed by that corporation.)


First rule of the Agile Rabbi: Don't attribute to Scrum that which is not related to the pillars that uphold it.

Thank you for stopping by. I hope to see you again. Feel free to leave a comment or question.

Stay Agile.

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more