Radiant Scrum (TM)

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 conclusions. Another issue to be aware of is when there are too many charts being displayed in succession using a slide show format. If there are too many slides or the slides are not shown for an appropriate length of time, the information will not radiate because the information is too hard to consume. 

 The main purpose of using an information radiator in a Scrum environment is to promote the Scrum pillar of transparency. It should help to keep the team focused on what is important and keep people outside the team aware of the progress of the team. As you can see information radiators help a team with the Scrum values of openness and focus.

 A team may use an information radiator to display any standard agile chart. It may show the teams progress thru a sprint or an epic. An information radiator can also be used to show the quality of the product via tests passing or other more technical information. The important part is to determine what information would be valuable to those inside and out of the team.

 Sprint or project backlogs can be good to display on an information radiator. The challenge with these is that it is often not easy to understand the stories based on their titles without additional information. I prefer to display Epic burnup charts showing how much of an epic has been completed. This helps to the team to focus on the epic and lets the rest of the company know how close we are to completion of the epic.

 I do find it interesting to note that the scrum guide makes no mention of information radiators, so they are not crucial to the success of scrum, but they are often very helpful to keep everyone focused and informed. The key to having a radiant information radiator is choosing the right place and the right way to display the right information.

 Here is hoping that your information radiator is as radiant as Queen when they sang Bohemian Rhapsody, and not as meaningless as parts of it. What is a scarmouche anyway?

 Stay Agile.

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

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
Read more

How many dysfunctions does your Scrum team exhibit?

Image
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
Read more

Feedback - Skills Relevant in the Torah and Today

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 Mo
Read more