Comments on: Managing chaotic situations by building “the list” http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/ Advance Your Business Analysis Career Thu, 09 Feb 2012 00:08:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Laura Brandenburg http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-6083 Laura Brandenburg Thu, 08 Jul 2010 23:15:17 +0000 http://www.bridging-the-gap.com/?p=1610#comment-6083 Hi Mark, Thanks for unearthing this post for me. It's been awhile and I had to refresh my memory about what I wrote. I like the action verb idea for helping wrap scope around a project and helping everyone get on the same page about what's in vs. out. One of the challenges I face in more chaotic environments is confusion about "what project is that request in?". Because there tend to be a lot of concurrent projects and shuffling of projects as resources become available or design decisions reveal unexpected overlaps in work, it can be a challenge to just remember what request goes where. Verbs might be a way out of that. This sentence stands out to me: "Part of the danger of chaotic environments is they often take shortcuts without realizing it." I think this is so true. When you are focused on the end game and the world around you is amok, it is easy to take a short-cut through the requirements. I also agree that the BA can often bring order to a chaotic environment. I often feel a bit like a sage asking the basic questions....what did we put into the requirements, how are they realized into design, what requirement is that bug for? Sometimes introducing these sort of structured conversations can have a calming affect on a team. Laura Hi Mark,
Thanks for unearthing this post for me. It’s been awhile and I had to refresh my memory about what I wrote. I like the action verb idea for helping wrap scope around a project and helping everyone get on the same page about what’s in vs. out. One of the challenges I face in more chaotic environments is confusion about “what project is that request in?”. Because there tend to be a lot of concurrent projects and shuffling of projects as resources become available or design decisions reveal unexpected overlaps in work, it can be a challenge to just remember what request goes where. Verbs might be a way out of that.

This sentence stands out to me: “Part of the danger of chaotic environments is they often take shortcuts without realizing it.”

I think this is so true. When you are focused on the end game and the world around you is amok, it is easy to take a short-cut through the requirements.

I also agree that the BA can often bring order to a chaotic environment. I often feel a bit like a sage asking the basic questions….what did we put into the requirements, how are they realized into design, what requirement is that bug for? Sometimes introducing these sort of structured conversations can have a calming affect on a team.

Laura

]]> By: Mark Jenkins http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-6076 Mark Jenkins Thu, 08 Jul 2010 12:26:09 +0000 http://www.bridging-the-gap.com/?p=1610#comment-6076 My approach, and the approach I now take with my analysts, is to first develop a complete, but very high level view of the project. This typically takes the form of what I would call "Power Verbs". These are the action points that you can then use to maintain your sense of the project. For example if the "project" was to move house. The power verbs might be Investigate, Decide, Prepare, Pack, Move, Unpack, Recover. As I go through a chaotic project, I make sure that no matter what we do, we at least have done something in those key areas. This can help to ensure that when you get to the end of your move house project, you don’t find you have left your pets at your last place! Translating this to practical, chaotic projects or environments, we spend time at the start of each project to blow out each power verb into a series of action areas. These action areas, on which we would brainstorm to complete, then allow the BA to ensure that, regardless of the process being followed, the project will at least cover the areas it needs to. Part of the danger of chaotic environments is they often take shortcuts without realizing. This method ensures that if a shortcut is taken, you can gain at least a sense of the risk or what you won’t cover. One added advantage is that this technique often allows the BA to bring order to a chaotic environment. By being organized and disciplined, the BA is often able to help bring the project team or the department into some kind of structured organization. My approach, and the approach I now take with my analysts, is to first develop a complete, but very high level view of the project. This typically takes the form of what I would call “Power Verbs”. These are the action points that you can then use to maintain your sense of the project. For example if the “project” was to move house. The power verbs might be Investigate, Decide, Prepare, Pack, Move, Unpack, Recover.
As I go through a chaotic project, I make sure that no matter what we do, we at least have done something in those key areas. This can help to ensure that when you get to the end of your move house project, you don’t find you have left your pets at your last place!
Translating this to practical, chaotic projects or environments, we spend time at the start of each project to blow out each power verb into a series of action areas. These action areas, on which we would brainstorm to complete, then allow the BA to ensure that, regardless of the process being followed, the project will at least cover the areas it needs to. Part of the danger of chaotic environments is they often take shortcuts without realizing. This method ensures that if a shortcut is taken, you can gain at least a sense of the risk or what you won’t cover. One added advantage is that this technique often allows the BA to bring order to a chaotic environment. By being organized and disciplined, the BA is often able to help bring the project team or the department into some kind of structured organization.

]]> By: Laura (Brandau) Brandenburg http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3861 Laura (Brandau) Brandenburg Mon, 23 Nov 2009 14:04:39 +0000 http://www.bridging-the-gap.com/?p=1610#comment-3861 Hi Steve, I couldn't agree more. I'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'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'd be interested to hear about tools and techniques that help balance both of these perspectives. Laura Hi Steve,
I couldn’t agree more. I’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’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’d be interested to hear about tools and techniques that help balance both of these perspectives.

Laura

]]> By: steve blais http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3857 steve blais Mon, 23 Nov 2009 09:12:56 +0000 http://www.bridging-the-gap.com/?p=1610#comment-3857 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. 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.

]]> By: Laura (Brandau) Brandenburg http://www.bridging-the-gap.com/managing-chaotic-situations-by-building-the-list/comment-page-1/#comment-3856 Laura (Brandau) Brandenburg Sun, 22 Nov 2009 21:55:24 +0000 http://www.bridging-the-gap.com/?p=1610#comment-3856 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 "next action" (something I also learned from Getting it Done) and add that to your "to dos" 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'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 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 “next action” (something I also learned from Getting it Done) and add that to your “to dos” 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’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

]]>