3. Alistair Cockburn (2000)
What is an Information Radiator?
A display posted in a place where people can see it as they work or walk by. It
shows readers information they care about without having to ask anyone a
question. This means more communication with fewer interruptions.
4. Why are they Useful?
More
communication
with fewer
interruptions
Better
communication
Important
information is
visible
You can’t yell at
a board with
stickies on it
Key to Project Success
5. What Makes a Good Information Radiator?
Big Simple
Maintained Location
13. Working Agreement
Typically used
at the start of a
project
Updated when
working
expectations
change
Offload burden
of process from
the team’s
minds
Can contain
anything
Can stagnate
but still useful
15. Project Health
Stats of areas
that need work
or are
important
Code
Coverage
Rules
Compliance
Code
Coverage
Cyclomatic
Complexity
Burn Down
New Internal
Project
Old External
Project
Specific Areas
Mentioned
16. Project Health
Used at stand
ups
Updated every
stand up
Visibility
Reminds and
Motivates the
Team
Code coverage
is a must!
19. Core Domain
Used during
discussions
about the
domain
Updated when
ever the
domain
changes
Updates
immediately
available to
everyone
Helps team
adoption of
ubiquitous
language
Critical to
DDD
Critical to
DDD
22. Architecture
Typically used
at the start of a
project
Updated when
ever the
architecture
changes
Everyone gets
to see the big
picture
Tend to
stagnate as
project
matures
Original Topic – Handy Information Radiators for a Software Project
Revised Topic – Information Radiators
Coined – 2000 by Alistair Cockburn.
Most popular – Agile Scrum/Kanban/Scrumban board
Definition – A display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.
More communication with fewer interruptions – People don’t have to bother people or search for interruption, it is immediately available.
Better communication – Radiators serve as focal points around which discussions can occur. This breeds richer and deeper discussions as all the important information is automatically brought into the discussion.
Important information is visible – Alistair Cockburn, “In a project people are emitting information all the time. Key part of a projects success is how fast people can get information from some one else.”
You can’t yell at a board with stickies on it – A Radiator provides a disinterested 3rd party with no bias which merely reports reality. This depersonalizes work helping to defuse those situations where tensions would be running high because of emotional attachment and personal biases.
Big – Easily visible.
Simple – Easy to understand.
Maintained – Worth looking at.
Location – Visible, close to team.
Description – Displays current work to be done and the team’s progress through that work.
Information Radiated – Work todo, WIP and complete. In this example we have a few more because of the workflow we setup for the project. What ever sections you have on your board they should represent the workflow on the project.
When To Use – Stand up.
When To Update - Updated in real time.
Usefulness – Everyone knows what everyone else is doing, the status and progress of work.
Specific Points – Evolve your board. Show on next slide.
New columns.
Descriptions in columns.
Velocity.
Column Limits.
Propagation of the ubiquitous language.
Description – Displays agreed upon things that are important to the development of the project.
Information Radiated – Shared understanding of working expectations.
When To Use – Typically used when starting a project, there after it helps new team members understand working expectations. There is nothing stopping you from creating a working agreement on an existing
project through, it is a great team building exercise.
When To Update – When working expectations change. This does meant that this radiator can become a bit stagnant on stable projects but it is worth keeping around.
Usefulness – Help bring important working processes to the surface. It offloads how the team should work together so that they can get on and do their work as apposed to worrying about how to work.
Specific Points – This can contain anything, this one talks very much to higher level processes such as sprint details when something is ready for dev/test, others have delivery dates, others have things like “be honest” and “don’t blame people”. It really depends of the maturity of the team and the project itself as to what information need to be agreed upon and what is general knowledge.
Description – Displays statistics that are most relevant to the current projects health.
Information Radiated – Statistics related to project health in areas that need to be worked on or need to be maintained. The one on the left only has code coverage and rules compliance issues since every thing else is healthy and it is an internal project so there is no burn down. We initially started out with only code coverage but add the rules compliance later because it started to become an issue where the team wasn’t constantly aware of the issue and the team lead would run around cleaning them up himself. The one on the right is an external project so it has the points to clear in the sprint and a burn down. Notice how the coverage in this one differs, there are references to specific classes, in this project coverage was an issue so it is a lot more active with richer information, this is a great example of using a radiator as a centre piece of communication. This project also suffered from high cyclomatic complexity so a section was added for that, again with references to specific classes ensuring that everyone is aware of them so that they can tackle them as they work.
When To Use – Stand up. Updated every morning.
When To Update – At every stand up.
Usefulness – Displaying these statistics help remind and motivate the team to care for these areas as the work. There is a lot of power in seeing something go up or down because of some work that you did yesterday.
Specific Points – I’d say that code coverage is a must, past that put up what makes sense.
Description – Displays a diagram of the core domain.
Information Radiated – Domain models, their relationships. Record of brain storming. Domain knowledge.
When To Use – During discussions of the core domain.
When To Update – When ever the domain changes.
Usefulness – Updates to the core domain are immediately available to everyone. Helps team adoption of ubiquitous language.
Description – Displays the high level architecture of the project.
Information Radiated – The big picture.
When To Use – Typically used when starting a project, there after it helps new team members understand the architecture.
When To Update – When ever the architecture changes.
Usefulness – Gives everyone a good idea of the big picture, this helps when people are working on small bits that need to work with other bits.
Specific Points – These seem to be pretty short lived as they get stagnant as the project matures. If everyone has the big picture and the team is stable take it down.
Description – Displays technical issues which couldn’t be solved immediately and/or were a cause for concern.
Information Radiated – Technical issues.
When To Use – Stand up, go through any new items in the red bin, either accept them or reject them. If accepted they can be prioritized into the current sprint, put into the icebox or left in the red bin for the next sprint planning. Sprint planning, again they can be prioritized into the sprint, put into the icebox or left in the red bin for the next sprint planning.
When To Update – At the end of every stand up and in real-time.
Usefulness – Issues bubble to the surface and are discussed by the whole team instead of being buried. Issues are prioritized into sprints. Collective brain power of the whole team focused on issues.
Specific Points – Borrowed from Lean Manufacturing Methodology where defective parts are removed from a production line as they are found and put into a red bin, at the end of the day or shift those parts are inspected and the cause of the defect found. This radiator came into existence because we had a newly formed team of people that hadn’t worked together much together, each had a lot of experience but did things differently, people were getting frustrated and the code base was becoming messy. As a potential solution Peter Wiles, our technical director, suggested we make a red bin. We’ve been in love with it ever since. Instead of issues causing frustration and friction there is healthy constructive discussion around them. Very often something that was initially thought to be a major issue turned out to have a simple solution that came out of the discussion.
Description – Displays a piece of information about a team member.
Information Radiated – Personal. This particular example is a count of how long one of the team members had gone with out smoking.
When To Use – Stand up.
When To Update – Updated by the person.
Effect – Builds team moral by supporting team members.
Specific Points – Team maturity.
Digital Radiators – Information closets. Prefer physical, only use digital when needed i.e. when a team isn’t co located. If you have to use a digital radiator it should meet the “Good Information Radiator” criteria.
Radiator Overload – Usefulness tied to Team agile maturity. Team maturity.
Raw data VS information – Raw data is useless, radiators must display data which conveys meaningful information.
Information Radiators help facilitate more communication in a project with less overhead, this is critical since projects succeed or fail based on the flow of information.
They should be big, simple, maintained and in a good highly visible location.
The list of radiators I’ve shared here tonight is by no means a complete one, experiment with your radiators, find out what works for your team.
The Red Bin is awesome, try it.