The Agile Rabbi

 “What’s in a name? That which we call a rose /  By Any Other Name would smell as sweet.” This line from Shakespeare's play Romeo and Juliet implies it doesn't matter what we call something. That its value and meaning are intrinsic in the thing itself.  Words have power, they shape our perceptions.  The pen is mightier than the sword . That phrase was penned in 1893 and is still very true today. How many times have you, or someone you know been taken in by an article on the internet just to find out later it was false? There was a recent survey to discover how many people fact check what they read on the internet . The result is that most of us don't fact check most of what we read and just assume it is true.  So, how does all this relate to DevOps? It matters what we call a collection of teams within an organization. What we call a collection of teams  is important. Are they Scrum Teams? Dev Teams? something else? The way that an organizatio...

"It’s easier to ask forgiveness than to get permission"  "It’s easier to apologize than to get permission"  We have all heard these phrases or something similar. I believe that there is a much better approach than asking for forgiveness after the fact, which is to Broadcast Intent beforehand. Be transparent with your intentions, tell people what you are planning to do. It is not asking for permission; however, it does leave an opening for conversation if others have questions or concerns. The phrases about forgiveness and permission are often attributed to Rear Admiral Grace Murray Hopper . She did help make their use more widespread, however the phrases didn't originate with her. Grace Hopper is one of the early pioneers in computer science. She coined the term debugging , although in her case it was the removal of an actual insect . Broadcasting our intent is something many of us do in our daily lives. Using turn signals when driving is a form of broadcastin...

When you team is ready to mark a story as done what do you do? Someone just closes the story? Have a team discussion? Other...? The Scrum Guide discusses the Definition of Done , but it doesn't discuss how to make sure that a completed story has met the definition of done. An additional question worth discussing is when a story is done, how does your team ensure they have completely met the acceptance criteria? The criteria that was agreed upon with the stakeholder to know when the story is complete. My team  has found value in creating an additional Scrum ceremony to solve this problem. The scrum guide discusses the standard five Scrum ceremonies, which are required elements of Scrum. Hopefully you are not just going through the motions of those ceremonies but actually doing them well and deriving value from them. That is for a post some other day.  The ceremony I am talking about is Story Closing . We have found great value in closing each story as a team...

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 M...

Status meeting are very important meetings for managers to learn about what the people that report to them directly, or indirectly, have been working on. A proper status meeting will gather all the participants around a large table, where the leader can clearly see everyone. There should be at least 15 people in the meeting, however it is much better to have between 20 and 25 people at the table, in addition to the manager leading the meeting. At the start of the meeting the manager should take a few minutes and speak about the current direction, or executive decisions made. After this each individual will give a short, 2 - 5 minute, overview of what they have been working on, including any challenges they are facing. The manager should then start to work with that individual, and anyone else needed during the meeting to come up with a plan to address any challenges. I am hoping that at this point you are thinking I must have lost my mind, It is April 1st today... Ok, and now for the...

This title of this post is based on a discussion at my office. We were discussing the importance of information radiators and how to sue them to make information about how our teams are doing highly visible. We want that information to radiate out and be easily consumable.   Information radiator is a term coined by Alistair Cockburn in his book, Agile Software Development . An Information Radiator is a display, often electronic, that makes information readily available. A good information radiator makes it very easy for people to consume the information. If the information is not easily consumable people will either ignore it or misinterpret the information.  Not all information radiators are good. Information radiators can radiate useless information or worse yet, misinformation. This can happen when multiple unrelated charts are displayed together. The viewer will look for the relationship between the charts where none exists and start to draw potentially incorrect ...

During this time on the Jewish calendar, it is traditional for us to spend time doing some deep introspection. Looking at our accomplishments and failures over the past year and building a plan to better ourselves for the coming year. In short, we do a deep personal retrospective and come up with our kaizen (Japanese for "continuous improvement") for the coming year.  This helps to highlight the importance of introspection and having a plan for improvement. To be able to improve a team must be able to take an honest and open look at itself. There are many difficult challenges in attempting to do so. It is very important that the team space be psychologically safe. Teammates must feel free to share their thoughts and ideas with the other members of the team without worrying that they themselves, or their ideas may be considered stupid. While this is easy to say, it can be unfortunately hard to achieve in practice.  A team that exemplifies the Scrum Values will find i...