In software development, however, the technique has some shortcomings:

• Problems and their causes are not always linear and you cannot always trace a symptom directly to a root cause by asking the 5 Whys.
• Sometimes causes are separated, in a significant manner, by time and space from the effect; this makes identification of the relationship difficult.
• Practitioners at times aim for the single root cause, but each question could elicit many possible root causes.
• The 5 Whys technique works well in simple and complicated environments; not so well in complex and chaotic conditions (see the Cynefin framework for definitions). Multi-causality, contributing factors, and not-so-obvious variables if ignored can lead the questioner to the wrong conclusions.
• Results are highly dependent on the questioner’s ability — stop too soon (at the symptom level) and you don’t reach the lower level root causes; stop searching after the first right sounding answer and you miss out on other plausible causes; treat a long-lived and unchallenged statement as fact and you limit avenues of investigation.
• The questioner’s level of knowledge is a limiting factor — ignorance can cause people to overlook causes they don’t already know about.
• Results aren’t repeatable and different people can identify different causes for the same problem.

It’s important to realize that we have more than the 5 Whys method in our toolkit. We can flow chart the process, use the Current Reality Tree (CRT) thinking process, or use Gerry Weinberg’s Diagram of Effects (my favorite). Which techniques do you use?

I found that a large information radiator for displaying project risks and issues has been well received by clients. The version I use is a simple 2×2 matrix. The two columns are used to classify items as Business or Technology related; the two rows to show whether the items are Execution or Coordination related — teams that aren’t smitten by the categories are free to change the headings to whatever makes sense in their context. Concentric rectangles denote when the effect of a risk will be felt.

Sample Risk Radar Chart

Items in the inner-most rectangle (or square or circle) identify current issues (risks that have come to fruition) or risks that will become issues within the next two sprints if not handled. The next outer rectangle shows risks that the team foresees materializing within the next 4 sprints. Longer timeframe risk items go outside the 4 sprint rectangle.

Color coding helps denote the severity/impact of the risk. Reds and Oranges affect the project more negatively than the Yellows and Greens. The Sunburst item in this case was a showstopper that was going to bring the project to a complete halt. The areas on the extreme right were for items that weren’t deemed worthy of being tracked on the risk-radar board just yet or for risks that had been taken care of.

For teams the goal was to handle risks before they became issues. Ideally, the innermost rectangle should be empty — teams should be proactively mitigating risks and taking care of them before they get into the innermost “Next 2 Sprint” rectangle.

We used large foam boards and masking tape for creating these risk-radar charts. The chart was prominently displayed in the team room and could be referred to during meetings.  The light weight foamboards made it easy for one person to carry the chart from one room to another if a meeting was being held elsewhere. Pictures taken with a digital camera were emailed to off-site participants.

Once a week, the Product Owner and ScrumMaster would meet with the development and QA managers and with business and IT stakeholders to review progress and roadblocks. During this hour long session, the group would discuss the issues and risks starting from the innermost rectangle.

This meeting served four purposes: (1) as a risk escalation mechanism, (2) as a mechanism for managers and stakeholders to remove impediments that were too big for a team to resolve on it’s own, and (3) as a mechanism for moving away from the existing one-way status reporting culture — managers and stakeholders were expected to report on progress (or lack thereof) on items they had publicly taken ownership of during the previous meeting, and (4) as a way for keeping managers from harassing the teams to “go faster”.

The reason this chart worked surprisingly well was: (1) it was always in everyone’s face and was hard to ignore, (2) managers had insight into risks and impediments and could proactively smoothen the way for the teams, (3) managers realized that teams could not go faster until the issues were taken care of.

Try it out on your next project and let me know what you think. Ideas for improvement will be highly appreciated.

“Al” was right on the money.  In a traditional or even many agile-lite environments stories are planned, tasks created and – at the very end of the sprint (if you are lucky) the test task is there.  Yup.  Here comes the latest in cool code.

It is like you build a car got it ready to roll and took it to the car wash.  When it comes out the other end you are really upset because it is full of water, soap, and all the pizza bones, old soda bottles, and that missing fooz ball are floating around in the  passenger compartment.  Jeez those clowns at the car wash should have been more careful.  Didn’t they see the windows were mocks, the roof was a shell, I mean all that was need was to clean the three little bugs off the windscreen and fine tune the horn.

In a more mature agile shop there would have been an acceptance requirement that the code had to be able to go through the car wash.  But even that level of sophistication will fail because it lacks the clarity of why it has to go through and most of all what it should look like after it is done.  three fourths of this car came out the other end, the wheels, rims, and interior were lost, and the team was incensed they could get the credit for the work that past. – all because the clowns at the car wash won’t take a broader view of the acceptance criteria – I mean come on dude, Most of it got through.

Then there is the business attitude toward the car wash employees.  The dudes with the rags get labeled surly, arrogant, and picky as the dickens when it comes to NOT doing somethings.  Business wants a good job for as little as they can pay for.  Look is it too much to ask for a clean car, vacuumed mats, windows that shine, as well as the removal of the unknown projectiles lodged in the mini-grill of the sub woofers stored in the trunk?  No I am not going to pay all that money for a detailing job so the car looks as good as new.  I just want to have it look that way for no additional cost.  And while you are at it, balance the engine, tune the suspension, lube it and put in the best oil and filter you can.

So thanks big Al.  We are all going to start moving to the tune.

I find that when starting with a new client and discussing the idea that we are going to put all their tasks and activities on a wall for everyone to see and so that it’s easy for the team to update, there is almost always push back or at least hesitation. The concerns typically are centered around the fact that “well we already have a dashboard system we use here to track project status and Sr Management uses it”. My guess is they have never seen a good story board/task board wall.

So where does the refrigerator part come into this?

Well, recently my refrigerator went on the fritz and stopped working, but I didn’t know it. I noticed that items coming out of the fridge seemed to be less cold, but I figured it was just me. So I didn’t do anything. Many hours later, the problem seemed to be worsening. Lo and behold, we had a problem and ended up losing a bunch of food in the refrigerator.  We had it repaired and all was fine, until it broke again.  This time the “breakage” was more obvious, but only because I was standing in the adjacent room (there was an electrical popping sound and a puff of smoke that came out from under the unit).  If I hadn’t been in the next room, again I wouldn’t have known something was wrong.

In the end, my wife and I decided to buy a new refrigerator instead of repairing the original.  The unit we purchased was half the price of the original unit (which was only 7 years old) but has more features and fit our needs better.  We purchased based on price, look and features, in that order.  It has a feature that I really didn’t notice/appreciate until it was in my kitchen and plugged in.  A digital display that shows the temperature of the freezer and of the refrigerator.  That’s the information radiator.  It even has an alarm built in alert us if the temp rises too high.  I could have a manual thermometer in the fridge and in the freezer to tell me the same information, but the difference is, I have to go look for it.  I would have to open the fridge, find where the thermometer got moved to and read it, just like a traditional dashboard.

With my new information refrigerator every time I am in the kitchen I know if things are working as expected simply by looking.  No digging for thermometers (or dashboards located on the web or in some program management tool somewhere).  So now if one of my kids leaves the door open or if it breaks (it better not, it’s brand new), I have a much better chance of knowing and being able to take a corrective action.

So what makes a good information radiator?

• It’s highly visible
• You don’t have to go find it, it’s just always there waiting for someone to look at it
• It is kept up to date – it’s simple enough that the team actually uses it and updates it and it reflects what the team is working on
• It can alert a team to a situation that needs corrective action – it doesn’t tell you what to do, it just displays the facts, we have to do the rest
• It’s simple

I love the information radiator part of my new fridge so much, I’m not sure I would ever want one without it.  Just like I would never want to run a project without an information radiator.  Once you see it and experience the simple power of it, you’ll know what I mean.

If you are a virtual team you have additional complexity to deal with.  BigVisible has built a virtual task board (information radiator) that is free for anyone to use, check it out at www.seenowdo.com

BigVisible Theme Prioritization Scoring Workshop – CSPO Class

Feel free to download and use.  It currently does not weight the relative benefit of implementing a feature (epic, theme or user story) nor the penalty of not implementing though adding the weighting capability is simple enough.

If you are interested in taking an public scrum class with me, check out training.bigvisible.com

Regards,
Giora Morein

I haven’t had time to create any user guides but here are a couple of things that I think would be helpful to know:

1. You will need to enable Macro’s for the sheet to work correctly
2. If you haven’t already done so, you will need to install the Analysis Toolpak Excel Add-In that comes with Excel.  From the Excel Menu, select Tools, AddIns.  Select the Analysis Toolpak and click OK.
3. After entering your Iteration Start and End Dates, click the “AutoShow Columns” button to automatically hide and show the relevant date columns
4. In the Status field, avoid using the “Fill-Down” capability to set the status of multiple fields.  Instead use copy-and-paste for the same result.  You can copy from a single status field and paste to a range of fields.
5. To have the burndown data for a specific day show up in the charts, you will need to enter an “x” in the field directly beneath the date
6. You can modify the categories by changing the list of categories in the table of “Category Burn-Down Data”
7. You can hide specific categories by removing the “x” next to the category name.
8. Send me a note for any additional help – I’ll do my best to get back to you quickly.

I’ve included two sheets: a blank tracker as well as one containing sample data.

Bigvisible Standalone Iteration Tracker v0.9.2

Bigvisible Standalone Iteration Tracker v0.9.2 – Sample Data

Enjoy
Giora Morein
gmorein@bigvisible.com