The Agile Rabbi

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 confl

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