General Musing

blaze your trail

Information Overload #scrum #xp #agile #risk

with 2 comments

After reading the Newsweek article “I Can’t Think!” I started wondering what the consequences are in SCRUM and XP teams of information overload. In my experience of SCRUM and XP there is a lot of information exchange, including Pair Programming and Test Driven Development even more possible information sources are forming a threat to the developers.

One of the best examples of my own experience is when I was working with ESB platform and Java Messaging (JMS). I had had no experience with the former and a reasonable amount of experience with the latter. I was asked to explain the inner workings of the software package I had had little experience with. The answer: “It does some magic, with a secret sauce!” was not enough to counter the fears of the PO who had made the choice to use the software. This caused me to need to get far more information about a subject to be able to explain in layman’s terms what was occurring.

The additional information I needed to collect was a stone around my neck for the initial introduction and understanding of the platform. And with the benefit of hindsight I should have said that I needed to get a basic understanding of the platform before committing to the demands of the PO. The downside was that we needed to be able to estimate the User Stories, and an estimation of 100 was a little excessive.

Read more articles on , or

This is an example of information overload caused by not able to put the learned information into a context. And there are a number of cases which of Information Overload which can occur in Agile methodologies that may cause teams to temporarily derail, as the article notes:

The brain is wired to notice change over stasis. An arriving email that pops to the top of your BlackBerry qualifies as a change; so does a new Facebook post. We are conditioned to give greater weight in our decision-making machinery to what is latest, not what is more important or more interesting.

Which in practice means:

  • incoming mail, text or instant messages
  • meetings
  • too many search results
  • other interruptions

As the article further notes:

Experts advise dealing with emails and texts in batches, rather than in real time; that should let your unconscious decision-making system kick in. Avoid the trap of thinking that a decision requiring you to assess a lot of complex information is best made methodically and consciously; you will do better, and regret less, if you let your unconscious turn it over by removing yourself from the info influx.

These are issues where the SCRUM Master is the gatekeeper to the team, and should factor in time in the day when these interruptions can take place.

Image source: Jerry Wong

Written by Daniël W. Crompton (webhat)

March 14, 2011 at 8:31 am

Posted in programming, risk

Tagged with , , , ,

2 Responses

Subscribe to comments with RSS.

  1. Yes of course it makes sense to do things in batches instead of real time.

    That is why Scrum’s backwards notion that everything should be done in real time with in person communication creates a lack of concentration which negates any benefits of scrum.

    Maybe if they would learn to use email and have offices with doors instead of bothering everyone all the time in person and interrupting their concentration everyone would be better off.

    Software Maestro

    March 14, 2011 at 10:30 am

    • I don’t believe that all of SCRUM can be written off, and this strengthens my argument that even interruptions should be scheduled.


      March 14, 2011 at 1:52 pm

Please Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: