The Agile Rabbi

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

Define accountability What does it mean to be accoun table in an agile environment?  Meriam Webster defines it as the quality or state of being accountable, of being able to answer. When something goes wrong, for example in production, i n some organizations being accountable means having to defend oneself potentially to keep from getting fired. In an agile organization being accountable means being required to answer two questions. Why did the event with negative impact occur? What will be done to ensure that it doesn't occur again? The first question is about discovering the root cause of the issue. There are many methods that can be used to perform root cause analysis. The key is getting to the factors that caused the issue. Without this information it is not possible to start to formulate an answer to the second question. Once we know why an event occurred we can plan how to prevent it from happening again. The plan must address the class of issues, not just t...

I would like to believe that most, if not all Scrum practitioners will respond that we should learn from failure, hopefully even embrace it. Recently a colleague of mine mentioned to me that our company practices Scrum very differently from his previous employer. Both organizations have the same Scrum on the surface, the same ceremonies, minimizing the amount of work in progress, and getting stories to done. A few minutes into our discussion I asked him "Did your boss ever ask why a failure occurred?" Of course they did was his response. I asked what their goal of asking why was. What I learned is that instead of asking "why?" in an effort to understand the root cause of the failure and how to avoid it, they asked that question to determine whose head to put on the platter in case someone needed to take the blame. It seemed he worked for an organization that was not interested in learning and improving and instead more interested in CYA (Cover Your A**). Comp...

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