The Agile Rabbi

Like baked good that have been around for too long story points also go stale. The expiration date for story points is typically four to six sprints after the stories are pointed. Once the points go stale, they should be removed from the story, and the story needs to be re-refined and repointed. After time has passed, the team will often point a story differently because of what they have learned from other work they have done in the intervening time. The team may now want to take a different approach to the story, so re-refining the story is the place to start. In a similar vein, when your team starts working on a project that they recently inherited from another team, all points assigned to stories by the previous owners of the project are, by definition, stale. Each team is unique in its knowledge and abilities so each team needs to assign points based on the effort they feel the story will take to complete. Additionally, teams often point differently, so the points one team assigns...

A recent sprint planning session with my team got me thinking about the importance of a Sprint Goal and how it is often glossed over. When well-crafted a Sprint Goal is very valuable to the team otherwise it is just a checking off the box for "do we have a Sprint Goal", which of course isn't very useful. Let's start by taking a look at what the Scrum Guide says about the Sprint Goal. the phrase Sprint Goal shows up 19 times in the current Scrum Guide. Under The heading of Sprint Planning - Why is this Sprint Valuable? , the Scrum Guide has this to say: The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning. The PO makes sure the team understands what value  they should focus on delivering in the current Sprint. The PO brings to ...

I have recently had some conversations about when it is appropriate to create a spike in Scrum. Is it when a team doesn't know how to approach a story? When they don't know how to utilize a tool or resource? When they have a question that they want to answer? Something else? I thought this would be a good time to dig into what a spike is, and what it isn't. The term spike comes from XP ( Kent Beck's Extreme Programming )  ( Spike | The Agile Dictionary ) .   A spike, paraphrasing  Ward Cunningham ,  should be a story that can convince the team that they are   (or aren’t)  on the right track.    One of the primary use cases of a spike is to help a team when they have a story that they are unable to estimate its size. Some stories are initially inestimable because there are questions that need to be resolved first. For example, the team may not know if a technology is appropriate; will it handle the expected load? In this case the team sho...

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

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