<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Managing chaotic situations by building &#8220;the list&#8221;</title>
	<atom:link href="http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/</link>
	<description>Helping business analysts become leaders and advance their careers.</description>
	<lastBuildDate>Fri, 12 Mar 2010 17:33:53 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Laura (Brandau) Brandenburg</title>
		<link>http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3861</link>
		<dc:creator>Laura (Brandau) Brandenburg</dc:creator>
		<pubDate>Mon, 23 Nov 2009 14:04:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=1610#comment-3861</guid>
		<description>Hi Steve,
I couldn&#039;t agree more. I&#039;ve regrettably discovered myself debating something that is meaningless in the larger context on occasion and always feel a bit guilty afterward. It can be easy to get caught up in what you want you are doing and lose sight of what you want to achieve. I actually think what you describe is one of the most difficult aspects of being an Agile Business Analyst. In this role, you&#039;ve got to keep your brain firmly planted on both sides -- part in the big picture and part in the sprint-level execution against the big picture. I&#039;d be interested to hear about tools and techniques that help balance both of these perspectives.

Laura</description>
		<content:encoded><![CDATA[<p>Hi Steve,<br />
I couldn&#8217;t agree more. I&#8217;ve regrettably discovered myself debating something that is meaningless in the larger context on occasion and always feel a bit guilty afterward. It can be easy to get caught up in what you want you are doing and lose sight of what you want to achieve. I actually think what you describe is one of the most difficult aspects of being an Agile Business Analyst. In this role, you&#8217;ve got to keep your brain firmly planted on both sides &#8212; part in the big picture and part in the sprint-level execution against the big picture. I&#8217;d be interested to hear about tools and techniques that help balance both of these perspectives.</p>
<p>Laura</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: steve blais</title>
		<link>http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3857</link>
		<dc:creator>steve blais</dc:creator>
		<pubDate>Mon, 23 Nov 2009 09:12:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=1610#comment-3857</guid>
		<description>I certainly am not arguing against keeping lists. I have many and occasionally during hectic times, lists of lists.  I was bringing up a few cautions about personal list keeping, most of which have tripped me up from time to time.  
Due to their dynamics, development teams using product backlogs (lists) or burn down lists do not usually manipulate the lists.  The public aspect of such lists is also a deterrent to gaming.  What does happen is that the team becomes so driven by the list that the overall product deliverable - usually months away - gets lost in the monthly sprints and daily scrums. Team forget that the lists are the decomposition of a larger objective and get lost in the details.  Because the team is focused on the next sprint, they lose sight of the big picture.  
This is not an argument against the process.  I know of no other approach to software development - or anything else - more simple and elegant.  Because of that there is a natural human tendency to give power to the process.  When the team spends an additional twenty minutes in a stand-up meeting debating the priority of three items on the sprint list, all of which are going to be accomplished in the current sprint, we can see how the list starts becoming more important than the results.  Another example is when there is an extensive and heated discussion about the wording, not the intent, of an entry on a list. Of course, there could be another explanation.  Since the process is so simple and elegant, we nerds as part of our nature need something to argue about, so we might as well debate the lists themselves.</description>
		<content:encoded><![CDATA[<p>I certainly am not arguing against keeping lists. I have many and occasionally during hectic times, lists of lists.  I was bringing up a few cautions about personal list keeping, most of which have tripped me up from time to time.<br />
Due to their dynamics, development teams using product backlogs (lists) or burn down lists do not usually manipulate the lists.  The public aspect of such lists is also a deterrent to gaming.  What does happen is that the team becomes so driven by the list that the overall product deliverable &#8211; usually months away &#8211; gets lost in the monthly sprints and daily scrums. Team forget that the lists are the decomposition of a larger objective and get lost in the details.  Because the team is focused on the next sprint, they lose sight of the big picture.<br />
This is not an argument against the process.  I know of no other approach to software development &#8211; or anything else &#8211; more simple and elegant.  Because of that there is a natural human tendency to give power to the process.  When the team spends an additional twenty minutes in a stand-up meeting debating the priority of three items on the sprint list, all of which are going to be accomplished in the current sprint, we can see how the list starts becoming more important than the results.  Another example is when there is an extensive and heated discussion about the wording, not the intent, of an entry on a list. Of course, there could be another explanation.  Since the process is so simple and elegant, we nerds as part of our nature need something to argue about, so we might as well debate the lists themselves.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laura (Brandau) Brandenburg</title>
		<link>http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3856</link>
		<dc:creator>Laura (Brandau) Brandenburg</dc:creator>
		<pubDate>Sun, 22 Nov 2009 21:55:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=1610#comment-3856</guid>
		<description>Interesting perspective, Steve. I tend to tackle big projects by breaking them up...yes this is the grooming aspect. Sometimes it can be helpful to identify the &quot;next action&quot; (something I also learned from Getting it Done) and add that to your &quot;to dos&quot; so you can make noticeable progress against a big hairy item.  But this is more for how I handle my own list of stuff to do. It&#039;s a different, though similar, process when you are talking about a list of projects and enhancements that will be prioritized and delivered by multiple stakeholders. What you describe is what I typically think of as the requirements process for software! :-)

Laura</description>
		<content:encoded><![CDATA[<p>Interesting perspective, Steve. I tend to tackle big projects by breaking them up&#8230;yes this is the grooming aspect. Sometimes it can be helpful to identify the &#8220;next action&#8221; (something I also learned from Getting it Done) and add that to your &#8220;to dos&#8221; so you can make noticeable progress against a big hairy item.  But this is more for how I handle my own list of stuff to do. It&#8217;s a different, though similar, process when you are talking about a list of projects and enhancements that will be prioritized and delivered by multiple stakeholders. What you describe is what I typically think of as the requirements process for software! <img src='http://www.bridging-the-gap.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>Laura</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adriana Beal</title>
		<link>http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3855</link>
		<dc:creator>Adriana Beal</dc:creator>
		<pubDate>Sun, 22 Nov 2009 21:42:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=1610#comment-3855</guid>
		<description>Steve,

I think that the main reason lists don&#039;t work for some people is because the list owners are not associating the lists with some sort of system to help them control the various aspects of their work and keep the optimum focus for themselves.

When we find a system that works for us, adding something already accomplished to the list just for the &quot;emotional payback&quot;, as you mentioned, should quickly lose its appeal. I find my list-based method  extremely useful to make sure that nothing of consequence is slipping through a crack, even when conditions change. A method like GTD is helpful because it goes beyond just keeping lists, allowing 20,000 feet, project-level, and action-level thinking.</description>
		<content:encoded><![CDATA[<p>Steve,</p>
<p>I think that the main reason lists don&#8217;t work for some people is because the list owners are not associating the lists with some sort of system to help them control the various aspects of their work and keep the optimum focus for themselves.</p>
<p>When we find a system that works for us, adding something already accomplished to the list just for the &#8220;emotional payback&#8221;, as you mentioned, should quickly lose its appeal. I find my list-based method  extremely useful to make sure that nothing of consequence is slipping through a crack, even when conditions change. A method like GTD is helpful because it goes beyond just keeping lists, allowing 20,000 feet, project-level, and action-level thinking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: steve blais</title>
		<link>http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3843</link>
		<dc:creator>steve blais</dc:creator>
		<pubDate>Fri, 20 Nov 2009 11:46:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=1610#comment-3843</guid>
		<description>I think everyone has some form of list that frames their working and social lives: lists of birthdays, special events, groceries to buy, things to do, etc. 
The difficulty with the lists, and why they don&#039;t work as well as they might for everyone is two-fold:  prioritization, and as Laura mentioned, the &quot;grooming&quot;.  
Lists typically fail by not adhering to Stephen Covey&#039;s quadrants made up of Important and Urgent (or any other consistent form of prioritization).  While this is a rationale way of handling lists it usually fails due to emotional implications.  Yes, it is more important and urgent to get that report done for the Committee and a favored co-worker&#039;s request is also somewhat important. Rationally we know the Committee report should be done first, but emotionally we want to help out our friend.  Besides, the job for the co-worker is easier and can be dispatched more quickly and that gets one of those pesky TODO&#039;s off the list and brings about that great emotional feeling of completion.  
Grooming is equally important and is not simply prioritizing and re-prioritizing.  According to the rationale time experts entries on the TODO list should be of equal work effort and take approximately the same amount of time to complete.  This is the same principle as WBS. The &quot;grooming&quot; is the constant review and revising of the list to break some tasks down to smaller activities and to combine some small tasks for efficiency.  Most people find that larger, more complex, more time consuming tasks on their lists are put off more easily because expected interruptions will break the flow of completing that task, so they do the smaller, shorter duration tasks - like straightening the desk, sharpening the pencils, or checking email  - instead.  Again, the emotional payback of removing tasks from the list comes into play.  
Lists are natural and necessary to make progress, or at least give the appearance that progress is being made.  The problem is in the manipulation of the lists once they are created.  And the subtle evil - spending more time rearranging, re-priotizing and re-grooming the lists to increase the emotional payback of crossing something off the list.  This includes adding something to the list - something that perhaps has already been accomplished - just so you can move it to the Done side.  The over-riding danger: instead of manipulating the lists to make our lives more productive and efficient, the lists start manipulating us.</description>
		<content:encoded><![CDATA[<p>I think everyone has some form of list that frames their working and social lives: lists of birthdays, special events, groceries to buy, things to do, etc.<br />
The difficulty with the lists, and why they don&#8217;t work as well as they might for everyone is two-fold:  prioritization, and as Laura mentioned, the &#8220;grooming&#8221;.<br />
Lists typically fail by not adhering to Stephen Covey&#8217;s quadrants made up of Important and Urgent (or any other consistent form of prioritization).  While this is a rationale way of handling lists it usually fails due to emotional implications.  Yes, it is more important and urgent to get that report done for the Committee and a favored co-worker&#8217;s request is also somewhat important. Rationally we know the Committee report should be done first, but emotionally we want to help out our friend.  Besides, the job for the co-worker is easier and can be dispatched more quickly and that gets one of those pesky TODO&#8217;s off the list and brings about that great emotional feeling of completion.<br />
Grooming is equally important and is not simply prioritizing and re-prioritizing.  According to the rationale time experts entries on the TODO list should be of equal work effort and take approximately the same amount of time to complete.  This is the same principle as WBS. The &#8220;grooming&#8221; is the constant review and revising of the list to break some tasks down to smaller activities and to combine some small tasks for efficiency.  Most people find that larger, more complex, more time consuming tasks on their lists are put off more easily because expected interruptions will break the flow of completing that task, so they do the smaller, shorter duration tasks &#8211; like straightening the desk, sharpening the pencils, or checking email  &#8211; instead.  Again, the emotional payback of removing tasks from the list comes into play.<br />
Lists are natural and necessary to make progress, or at least give the appearance that progress is being made.  The problem is in the manipulation of the lists once they are created.  And the subtle evil &#8211; spending more time rearranging, re-priotizing and re-grooming the lists to increase the emotional payback of crossing something off the list.  This includes adding something to the list &#8211; something that perhaps has already been accomplished &#8211; just so you can move it to the Done side.  The over-riding danger: instead of manipulating the lists to make our lives more productive and efficient, the lists start manipulating us.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
