Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Moving to Agile
Previous Previous
 
Next Next
New Post 6/6/2008 6:36 AM
User is offline Jarett Hailes
155 posts
6th Level Poster




Re: Moving to Agile 

I'm sorry, I don't think you quite understood the point of my statement.  It wasn't to force the business into receiving something they don't need anymore.  Let's say we've got a project with 22 different business groups working with a central system (this is based on a current example of what I'm doing).  Everyone has agreed, in writing, to a certain spec.  Suddenly, 1 of these groups demands that additional functionality be added/changed/removed in order to accomodate their 'changing business practices' (read: they are trying to get something in they wanted from the start, but did not get enough support from the entire community to have it included).  This change will have a major impact on the entire solution, and cause other partners to have their change their technology and business processes. Now, repeat this situation with at least a dozen of the 22 groups.  Without a good change management process, these types of little 'requests' can quickly derail a complicated project. 

Working in a multiple, independent stakeholder environment means that change must occur more slowly than in a situation where a single business is in control of the entire environment.  Without a way to ensure that changes are rigorously debated, refined, and eventually agreed upon (for inclusion or exclusion), such a project will go absolutely nowhere.  This may not satisfy your condition of providing the right value to some of the customers, but in my mind for such a large project you have to try and satisfy the vast majority.  If you end up building something that no one is happy with, then you've failed.  But if you are able to deliver something that most, if not all of them, agree satisfies a certain need, then you've done well.  Usually the key is to focus on providing some broad value to many initially, since there is usually a small piece that everyone can agree on, but will disagree on the rest since they all do things differently.  Then, once you've delivered something, you can look at doing more with those who have similarities between their processes (or are willing to change them), and continue to iterate...

 

 
New Post 6/6/2008 6:56 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Practical tips Re: Moving to Agile 

Some practical advice;

Focus on getting the develoeprs into the same room as the client.

Get the developers onto the shop floor of the client for a day or two so they can get a full contextual view of the end user environment.

Up front focus on requirements visioning - big picture stuff rather than details.

When working on eliciting requirements - do it with the developers in the same room.  The focus should be on clarity of understanding not on quality documentation of requirements.

Spend most of your time in the client's domain and act as their eyes and ears on the project, not the other way around.

 
New Post 6/16/2008 1:15 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Moving to Agile 

The way I learned BA is that our primary tasks are to first simplify and then integrate and automate.   I also learned that probabaly the biggest payoff was in simplifying.    Is there any focus in Agil  on simplifying the as-is, before moving on to the to-be?

Tony

 
New Post 6/16/2008 6:17 PM
User is offline Jarett Hailes
155 posts
6th Level Poster




Re: Moving to Agile 

Hi Tony,

What exactly do you mean by 'simplifying the as-is'?  Are you talking about performing business process re-engineering before adding a new system to the mix?

 
New Post 6/17/2008 6:15 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Moving to Agile 

Larimar:

I guess you could call it business process re-engineering, although it does not necessarily need to be always enterprise wide.  If the scope of the effort is relatively narrow, one might call it a mini-reengineering or something.    Is'nt such "reengineering" within the scope of what a BA does?   Shouldn't it, in fact, be the major thing that a BA does?     After all, it is called "Business" analysis.  

And if BA's are charged with doing such reengineering, shouldn't they be most focused on as-is modeling, instead of jumping right into to-be modeling, as is typically the case with Use Cases?

Tony

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Moving to Agile

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...

 



Upcoming Live Webinars




 

Copyright 2006-2021 by Modern Analyst Media LLC