The Agile Rabbi

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

DevOps, one of the current buzzwords in the industry. It is as important as Agility to the delivery of software and because it crosses traditional departmental boundaries, it is harder to achieve. Similar to the way that Agile / Scrum practices broke down the barriers between Development and QA, DevOps, done properly , removes the barriers between Development and Operations. There is a natural tension between Development and Operations. On the Development side WE want agility and on the Operations side of the wall THEY want stability. Right there, if you read carefully, is the challenge, we and them. With DevOps we can satisfy both sides because both sides gain an understanding and an appreciation of the other perspective and learn how to move forward in a safe stable manner so we don't negatively impact customers, but also in an agile and quick manner so that we can continuously provide value to our end users. As Donovan Brown, a Principle DevOps Manager with Microsoft, said ...

In an Agile world delivery should be just like voting in Chicago, early and often . As per The Principles behind the Agile Manifesto , the first one says "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." (emphasis mine) A UAT environment (User Acceptance Testing) where users test the software, log bugs, wait for updates determine if they will accept the release into production, where someone outside of the Scrum Team determines when the testing is complete, prevents us from delivering the product to the end users. There are a number of reason that I have seen for why UAT environments are created 1. We need to verify that the data is being edited correctly by a tool 2. We need to make sure that this new functionality will satisfy user's needs 3. It isn't really UAT, it is just misnamed Let's address the third one first. If this "UAT" environment is where the product is staged s...

In my previous post about accountability there was an implication that for someone to be held accountable expectations must be clearly set and there must be a commitment to meet or exceed those expectations. Without clear expectations it is unclear to me how one could be held accountable since the accountability is a direct reference to those expectations. As an example, a Product Owner is accountable, responsible to use the terminology in the Scrum Guide, for managing the Product Backlog. In the Scrum Guide there are five bullet points that detail that responsibility. For the Product Owner to be held accountable for proper management of the Product Backlog the Product Owner and the business, often read the Product Owner's direct manager, must have a shared understanding of what that expectation means. The Product Owner must understand that their role entails making a commitment to meet or exceed those expectations or they are in the wrong role. When discussing expectations i...