The Wall of Pain

Jul 20, 2011  ·  Mike Lowery

Software projects experience a problem called technical debt. In short, technical debt is the result of making a quick and dirty work around (often for valid reasons such as deadlines) which creates rework later.


I recently visited an organisation that had a wall of pain which I thought was an excellent idea as it highlighted the levels of technical debt in the project. This involved a section of the workspace dedicated to items that needed refactoring at a later stage. This made me think about pain and our tolerance to it.


The wall had lots of pain on it and the team did their best to address this pain whenever they could, a commendable exercise for any team.


That said I am not sure how much the pain was actually felt, as I said there were lots of cards and they were not easy to see when the team did their stand up in front of the visible workspace, so they did not feel like they were always on the mind of the team.


So how about including the wall of pain on the visible workspace, seems like a great place for it, it is in your face, the team have to look at it. The scrum master can coach the team in dealing with this debt and the team can see it change size and do something about it.


All this is a great but I still think the this could grow or if it got too large people may feel reluctant to add more to the board.


This lead me to think about how I could still have the wall of pain and feel it too, using square “post it” notes make a grid on the visible workspace 2×2, 4×4 etc, each time you incur debt add a note to the board and fill up one of the grid slots. Once the grid is full you have reached your capacity for pain, any new debts mean that something has to be done to relieve the pain. This makes for a gentle reminder to not take on too much debt and to not forget about fixing it.


The wall had a lot of pain on it and the team did their best to address this pain whenever they could, a commendable exercise for any team. That said I am not sure how effective this use was. There were lots of “pain cards” and they were not easy to see when the team did their stand up in front of the visible workspace, so it did not feel like they were always on the mind of the team.


So how about including the wall of pain on the visible workspace? This is a great place for it: it is in your face, and the team have to look at it every day. The ScrumMaster can coach the team in dealing with this debt and the team can see it change size and react when it starts to grow.


There is still a risk here though. The wall of pain could grow to unmanageable levels or, if it got too large, the team may feel reluctant to add more to the board.


This lead me to think about how I could still have the wall of pain and feel it too:


  • Using square “post it” notes make a grid on the visible workspace 2×2, 4×4 etc

  • Each time you incur debt add a note to the board and fill up one of the grid slots

  • Once the grid is full you have reached your capacity for pain. To incur any new debt you will need to relieve the pain by removing technical debt items.

This makes for a gentle reminder to not take on too much debt and to not forget about fixing it.

Categories:

Tags: Agile, technical debt.