Hello Phill

I hope it is already been 4 months for you working on Agile methodologies

I just joined this group and I could see your question but could not find any satisfying answer so I would like to share what I know

1. Agile is a Methodology (Not a model or a framework) under which you have different models such as Extreem programming, Scrum and DSDM etc. but most prominently used models are Extreem programming and Scrum

2. Agile is known as Light weight model because it has No or less documentation present in it.

3. Agile best suits for the projects where the delivery of the application or the product is immidiate in nature.

4. Through Agile methodology you actaully deliver a project or a part of a project with in short periods

5. Here Developers are kings and they run the whole show and client interaction (participation is the project)  is high and feed backs are rapid

6.some times the product can be developed and delivered to the client with in 30 days

7. Code it self is the documentation and their by further enhancements in future might take little longer

8. By this methodology one can give a quality product but their will always questions arises on it's architecture and design ( it will not have robust architecture i.e scalability and extendability of architecture).

I got some content this might help you

Best practices for increasing the agility of documentation:

1. Writing

   • Prefer executable specifications over static documents
   • Document stable concepts, not speculative ideas
   • Generate system documentation

2. Simplification

   • Keep documentation just simple enough, but not too simple
   • Write the fewest documents with least overlap
   • Put the information in the most appropriate place
   • Display information publicly

3. Determining What to Document

   • Document with a purpose
   • Focus on the needs of the actual customers(s) of the document
   • The customer determines sufficiency

4. Determining When to Document

   • Iterate, iterate, iterate
   • Find better ways to communicate
   • Start with models you actually keep current
   • Update only when it hurts

5. General

   • Treat documentation like a requirement
   • Require people to justify documentation requests
   • Recognize that you need some documentation
   • Get someone with writing experience

I am trying to throw some light on this and do write me if you need more information.

regards

Sagar

Well I am now getting on for nearly 18 month working with Agile. In that time i have learnt it, moved jobs ang implemented it into a dev team. It is working really well, and the out put is seeming to be of greater quality and less time needed to develop. We have bought licences for VersionOne which has been really useful as the team lean agile really quickly due to the way the tool works. Just the business next who need to get to grasps with it.

I kind of agree that 'Just Enough' is a little missleading, i have come across one of two product owner eho use it as an excuse of getting out of documentation. I like to document, but keep it simple. Just so i have soething to sign off against.

I have implemented the formal way of writing userstories, here in my new place, which is prooving successfull. The dusines are starting to think much more about their requirements, and what is it there actually trying to achieve. Format of userstories are: "as a [customer] i would like [request] for the following [reasons]".

Anyway keep sharing best practise is that i am learning. Sprint retrospectives are great for capturing dev feedbeack, and sharing with other product owners.

Hi,

I look at "Agile" as more of a philosophy rather than a specific set of guidelines - it's a style of dealing with projects rather than something that replaces the traditional waterfall model.  Ultimately, in my opinion, everything boils down to the Software (or System) Development Lifecycle - SDLC.  If we take a look at it, it has some very concrete steps:

Analysis -> Design -> Implementation -> Maintenance -> Planning -> Analysis -> Design -> Implementation -> Maintenance -> Planning -> Analysis .....

Notice, that I've tried to represent this as a cycle - where the first step can either be Analysis, or may be Implementation or, may be you come on board onto a project where you are within the stage of Maintenance ... it doesn't matter - what matters is that first and foremost you recognize which stage of the project, you've arrived in.

Each of these steps are a context within themselves and each require the need for a Business Analyst.  If we are talking about each of these steps within the "Agile" context and we abide by the "Agile" mantra: "Just barely good enough", I usually follow these steps:

1. Identify first and foremost the bigger picture for the stage you are in.

2. Identify all the actors within the bigger picture.

3. Identify the responsibilities of all the actors ("actors" may not mean people - it may mean anything that has an impact on the system you work with - so it can be processes, people, other systems etc....)

4. Break down the bigger picture in stage 1 by the responsibility of each actor you identified in step 2

5. Break down each of the actor's responsibilities and / or tasks identified in step 3 into actions (where each action is defined as a set of pre-conditions which result in a set of post-conditions based on a number of variables or constants passed to the actor for a given task).  Of course you need to identify what each of the pre-conditions / post-conditions are based on the variables or constants passed to the actor for the tasks you've identified and so on ....

What you will notice yourself doing is eventually drilling down from a very general scope to a very narrow scope through each iteration as you simply try to identify the "Just barely good enough" components / modules / actions / whatever that make the system operational within the scope of the SDLC stage you found yourself in.

Ultimately, I see the responsibility of the business analyst to be the individual who makes sure that the scope of the project meets the overall expectations of the top project stakeholder.  With the approach I try to use above, I generally manage to have a much better contextual understanding from a big picture perspective, as well as a low-level understanding of whether the project as is, meets the requirements within the SDLC stage I find myself in.  If not, as a business analyst, you should communicate to the team that you see gaps which have the potential to affect the ultimate goals of the project.

You will also notice that as you drill down from above, you will have a much better understanding of the system and as such will be much better equipped to design test scenarios which will ultimately decide if the project is being implemented in a way satisfying business requirements.

I hope that I've posted something which adds value to the general discussion - this is a topic which could go on for a lot longer than this post ....

Cheers,

Michael

Sr. Business Analyst @ Fidelity Information Systems