Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Moving to Agile
Previous Previous
 
Next Next
New Post 5/20/2008 7:34 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Moving to Agile 

I have seen some great work done with activity diagrams and use cases on smallish systems.  However, it has always been my experience that  mixing the UML functional modeling techniques with larger scale efforts spells big-time trouble.  Proper analysis requires postponement of implementation aspects until the appropriate time.   Use cases, by their very nature, are implementation oriented; they force the analyst think of solutions too soon.

Remember, agile does not propose any new modeling techniques, and proper use of modeling is key to success.  Don't let the latest buzz word cause undue confusion.   I would focus on gaining a clear understanding of what the important differences are between functional modeling techniques.  

Tony

 

 

 
New Post 5/20/2008 4:43 PM
User is offline Chris Adams
319 posts
5th Level Poster






Re: Moving to Agile 

 ajmarkos wrote

I have seen some great work done with activity diagrams and use cases on smallish systems.  However, it has always been my experience that  mixing the UML functional modeling techniques with larger scale efforts spells big-time trouble.  Proper analysis requires postponement of implementation aspects until the appropriate time.   Use cases, by their very nature, are implementation oriented; they force the analyst think of solutions too soon.

Remember, agile does not propose any new modeling techniques, and proper use of modeling is key to success.  Don't let the latest buzz word cause undue confusion.   I would focus on gaining a clear understanding of what the important differences are between functional modeling techniques.  

Tony

 

I think most people see use cases as implementation oriented because they write them as such.  I have always told my analysts to avoid any reference to screens/UI design.  I should never see the name of a screen, dropdown list, button, etc.  A maintainable system use case should only describe the functional requirements required for the system to provide the appropriate response to the user, not how that should be implemented in screen design.  If two screens that support 20 functional requirements split into 3 screens in the future and use different control types, I should not have to re-write my use case if it was written properly the first time.  Admittedly, this is not easy to do.  Especially for people who are new to use cases.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 5/20/2008 5:01 PM
User is offline Chris Adams
319 posts
5th Level Poster






Re: Moving to Agile 

 vneytcheva wrote

Topny,

Thank you for the quick response.

Our systems are complex, with plenty of business rules. It is the healthcare domain.

I would like to continue using use cases and UML.

-Vessela

Vessela,

I have yet to be part of a formal Agile Project.  Yes, I said formal Agile Project and no that isn't contradictive.  Even an Agile Project should follow a structured and agreed-upon process, even if that process is lightweight with minimal documentation.

I have read a bit on Agile and also heard from some colleagues and friends that have been on Agile Projects.  Most people, with the exception of the hard core Agile promoters will agree that Agile has it's place in the IT systems world, but isn't great for everything.  It often can be useful on small or even medium size projects in some cases.  However, most agree that it is not good for large, complex projects. I'll give an example of why in a bit.

I have also seen a few informal internal projects (the unofficial projects where the Dev team works directly with other teams to put together a feature list for a new tool and then codes it iteratively using short 1-2 weeks intervals for releases and feedback).  It can work well.  But it also has shown me spme major risks of Agile.

Imagine setting out to create a large and complex system, or even a small system that was initially intended to meet only certain needs (requirements) but eventually grows into a more complex system that can handle many more requirements.  If you have not performed enough analysis upfront to identify the majority of the requirements, or if the requirements change on you rapidly you will most likely find yourself with one of the following problems:

  1. The system architecture can no longer support the newer requirements because technical design decisions were made based on the initial set of requriements
  2. In order to support the new or altered requirements, you need to redesign a major chunk of the intial system (imagine how costly this becomes if it happens a few times)

These are just some things to watch out for.  I'm sure some people have pulled off large scale Agile projects, but they certainly have their risks.

Also, beware of the companies that like to use the latest buzz words.  While you may be using SOME Agile practices, it sounds like your organization is really using more of a hybrid approach.  This may help you overcome some of the inherent risks associated with Agile on large projects.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 5/20/2008 7:40 PM
User is offline Jarett Hailes
155 posts
6th Level Poster




Re: Moving to Agile 

Chris,

I really appreciate your perspective on this - even on small projects Agile 'just enough' requirements analysis can cause problems - thinking you have enough requirements to get started without going deeper into the customer's needs can wreak havoc with project scheduling, timelines, deliverables, etc.  Agile seems to gloss over this a bit with the stated thinking that the project could and should continue indefinitely until the customer is satisfied that they have 'enough' functionality done.

I agree that bigger projects need at least a set of high level requirements that will frame the overall solution, particularly since some of the major tenets of Agile do not hold (for example, the business can't clearly state major requirements initially, they will change their mind, etc.).  Then functional portions can be broken off and treated as sub-projects that follow a more Agile methodology, if so desired.  Even in those instances, I feel strongly about getting the vast majority of requirements up front along with formal change management to ensure that the Agilists don't start implementing new requirements that no one has really analyzed properly (i.e. some developer threw a new 'task' on the product backlog without the business team validating it, making sure it meets a business need, and is properly approved and tracked).

Lastly, projects involving multiple stakeholders (which occurs in many government projects) with disparite interests almost demands a more traditional approach.  It's hard enough to get them to agree on anything in the first place, we can't give them the ability to change their minds unilaterally (whether it's approved or not).  Change management does indeed become a form of 'change prevention' in this case, which Agilists can view negatively but in this scenario I view it as necessary and in fact beneficial to the success of the project.

 

 
New Post 6/6/2008 12:44 AM
User is offline Akshay Dhavle
1 posts
agileanalysis.blogspot.com
No Ranking


Re: Moving to Agile 

"Change management does indeed become a form of 'change prevention' in this case, which Agilists can view negatively but in this scenario I view it as necessary and in fact beneficial to the success of the project."

I am so sorry to hear that again. For me "success of a project" is that it provides the right value to the customer. You, like many others, seem to define success of a project as a team delivering what was written in a spec when the client (most probably) didn't know what he wanted.

If you see that the customer is making changes which don't make sense given the business objective, it's valid to try and prevent that change. But "change prevention" just so that you can stick to your plan goes against the basis of the IT industry. IT was born to help business run smoother with the help of technology, wasn't it?

 
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