Hi all,
I am fairly new to being a business analyst within an Agile environment. It has been a huge learning curve with many challenges. Within the organisation i work in, there are 5 business/system analyst whom have various amounts of experience as well as techniques they use. I want to set a group up in the organisation to share best practices, discuss topics that they may need help on etc etc. I am wondering if anyone has already done something like this and could help me with some ideas on the best ways to approach this.
My goal is to develop an agile framework of best practices within the company as well as helping develop the analyst’s skills and understanding.
I look forward to hearing your ideas.
Thanks
Phill
Hi Phil:
Congrads on your new role and kudos for you for wanting to take the lead on sharing practices, etc with your project community.
Many orgs i work with use a wiki to do this. holding lunchtime discussion on an article or book, swapping with someone leading a discussion on how you handled a situation on a real project, and watching then discussing a webinar together or power ways to share and learn. (some call these "learning circles"). combine that with an online wiki (or some other shared space) for the best learning.
I put together a short list of suggested reading for the agile analyst (including a number of assets from myself on the first page), i hope this might be useful to you: http://www.ebgconsulting.com/agile-ModernAnalyst.pdf
all the best,
~ ellen
Ellen Gottesdiener
EBG Consulting, Inc. Principal Consultant [email protected]
Twitter: www.twitter.com/ellengott Subscribe to our eNewsletter: Success with Requirements
Upcoming: Agile Requirements public training: 6/16-17
Phil:
The agile modeling mantra "model just enough" is a sound bite - not a best practice. The essentials (i.e., the unchanging "just enoughs") of functional modeling have been know for a long time : Identify the process and, most importantly, the process's inputs and outputs. However, with agile, on one hand the analyst is told to model the essentials (i.e. model just enough), but on the other hand, the analyst is told to forget about the essentials, as the functional modeling techniques most frequenetly associated with agile - Use Cases and Activity Diagrams - pretend that inputs and outputs do not exist (at least not at the graphical model level - where they most need to be incorporated).
You can not develop concrete best practices around an ill thought out sound bite.
Tony Markos
I'm new to agile too and the above certainly isn't the impression I'm getting from implementing agile methodology. Everything I've read simply says to use the most appropriate tool for the job.
A pretty simple diagram will often do the job - we often just take a photo of something we've drawn on a whiteboard or flipchart paper. If the developer was involved in the conversation that took place (and they always should be!), this is enough to remind them what they need to develop and should note anything they thought was important at the time. Documentation of what goes into the live environment will be more detailed so anyone who needs to revisit it can easily grasp what has actually been produced.
Back on topic... we've currently got a somewhat muddied set of tools for sharing ideas and best practice. We have a weekly meeting which all the BAs and SAs have an open invite to in which we discuss what is working and what isn't. We also have a sharepoint site which the BA team use (or not as is usually the case) and we're looking at setting up something like Yammer (www.yammer.com) for quick and easy communication and discussion.
@Tony - not my experience at all. Model just enough, but realise that 'just enough' includes more than 2 weeks work in the early stages of a project. A context and dfd diagram is a perfect requirements tool for this dev process btw.
@topic - I use lunchtime learning sessions - each team member takes a turn to present and host a discussion, and the scrum retrospective. Fostering reflectivie practice is my main goal.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: