Thanks for an interesting article. I do appreciate the intent of the author to educate/inform the readers about what a 'traditional' BA would need to do to adapt to Agile methodologies/principles. However, based on my experience working on projects/product(s) executed using Agile Methodolgies, I believe the following points need more clarification:
1.Improve estimation (Look into Wideband Delphi principles)
By this, i take it to mean that the BA's should play an 'advocacy' role in encouraging 'empirical' estimation techniques employed by the Lead Developers/ Development team. As it is, BA's do NOT directly participate in estimation activities, as it is best left to the 'scrum' team....
2. Fight bureaucracy where-ever you can.
Again, a 'motherhood-apple pie' kind of sentence. Ofcourse, I hear you when you say let us fight bureaucracy, but in the real world, it gets complicated, especially when we have multiple stakeholders spread across functions.
But I do take this to mean that , The BA has to exhibit leadership skills as he/she has to manage multiple stakeholder expectations, but has to work with his 'loose' span of control...
Once again, thanks for sharing a very interesting article.
2.
Market Agility (i.e. responsiveness to the business environment)
Very hard to accomplish. Enter the infamous three part lag.
1. Change in business environment and it's effect on the business must be recognized.
2. How to fix the problem.
3. Did the fix work? did the problem get fixed.
4. If problem not fixed go to 2.
Unfortunately, each of these three lags can take may weeks or months to resolve.
In the mean time workers become unemployed, company's fail or some other entity
buys the remains.
Regards,
Zarfman
BA's will want to explore this topic as agile methodologies are brought into more and more organizations.
The greatest impact to our profession may occur when emphasis shifts from documentation to code production. At the same time, requirements are addressed in iterative cycles, rather than a continuous waterfall from analysis to design to coding to testing.
Agile development does not preclude the need to capture requirements and to instantiate them 100% in software tests. A critical need remains for accuracy and a correct level of detail. Only the process - the methodology - changes.
BA's who wish to better understand the new processes might turn to a few books, such as...
> Extreme Programming Explained: Embrace Change by Kent Beck
> Balancing Agility and Discipline by Barry Boehm and Richard Turner
> Adapting the Rational Unified Process by Stephan Bergstrom et al.
> The Enterprise Unified Process by Scott Ambler et al.
For an immediate start, Wikipedia offers a long thread of articles on the subject.
Thanks for the article Colart.
While I think ou raise many good points I think you have omitted a key issue for the traditional BA mving to agile: How do I manage requirements for an incremental build?
Would love to hear your thoughts on this topic.
Thanks for the article - it was very good. There's two points I'd like to make though:
* The primary value a BA adds on an Agile project is acting as the user advocate in the project team. So many agile methods assume a customer reresentative available to answer questions quickly, and when (invariably) the business blanches at this the BA steps into the breach.
* The suggestions you gave for improvement could apply to any project, no matter what the methodology. What's different specifically for agile?
There's certainly a lot of challenges for BAs moving into Agile projects. Especially as many development-types who promote Agile have a view that direct developer/user interactions and demos renders a BA obsolete.
In my (admittedly few) "agile" projects I've found myself producing pretty much the same information set, just using cut-down tools (Wikis, issue tracking), and doing the same tasks (Workshops, demos, user interviews). It was just in parallel with development instead of up front.
Repost of a LinkedIn Comment:
Interesting that you are asking this question, as I was asking it myself a few months ago. This seems to be a re-occurring question and deservedly so. When Agile “seems” geared to getting development done and it’s lifecycle, how do you incorporate the non-developer team members?
I did some research and found a number of articles, blogs, etc. that touched on the topic. I aggregated a few thoughts, which I can list here. Some of these my own thought, while others are not. However, I don't have the references to others work. I apologize to those folks. At the time these notes were for my own edification, not for future publication.
- Documentation Tasks
1. Document the current or new process, to assist in training
2. Generate status reports in instances where people won't attend Stand up meetings -or- insist on a Scrum-to-Waterfall translation (e.g. red/yellow/green status vs. examining the burn down chart).
3. Release notes
- A BA can become a tool that others on the team utilize to accomplish their tasks. Part of self-organizing requires one to look at the problem and determine the best way they can be a part of the solution.
- A critical skill that an agile BSA brings to the table is the ability to investigate and understand how the business actually works, as opposed to how developers think it works or want it to work, an ability that they should be able to mentor developers in. When co-located, Agile BSAs would also perform non-BSA activities as well, perhaps pair programming with one of the developers on some of the business code or working with users to develop acceptance tests. This way the agile BSA would grow his or her own skill set over time and would help others to do so as well.
As time has progressed and we've started our first sprint with a BA team member at 50%, I've realized a few things first hand:
1. SCRUM (the flavor of Agile we're using) really is self-organizing. AKA team members (not just BA's) must be self-starters. They don't need to know the answer to every problem, but they do need to have the confidence to throw their hat in the ring and say "Hey, I'll tackle that problem. Who can help me ... better understand, research, design, etc.". We all do better in a collaborative environment, but you do have to have the chutzpa to jump in. To that end, if the BA has a desire to learn more about the technology being used, they can help the tech guys. Maybe they can assist the testers in a "test heavy" sprint. Developing test scripts or user manuals may be needed and might provide an opportunity to explore a new piece of software. The exact tasks may change each sprint, but that's part of the theory of SCRUM and self-organization.
2. On a more concrete note, one worthwhile task is to have the BA learn more about a process that the team will be addressing in the near future. Not a SME per-se, but someone who understands the needs and directions and knows where and to whom to go for more detailed information. This will help the team generate better, more accurate user stories and can provide a single point of knowledge on this subject. Again, not an end all, be all SME, but a good resource for the team. We are exploring this choice and we'll see how successful we are.
That’s my quick two-cents…for what it’s worth.
By
Sean McInturff Owner, ISI Solutions, Inc.
posted 14 days ago
(http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=23267795&gid=43421&trk=add-news-lnk-0Ot79xs2RVr6JBpnsJt7dBpSBA)
Repost of a LinkedIn Comment:
Thank you for posting this article. There is clearly a lot of meat here for discussion.
The first element that popped out for me was the emphasis on empirical research that prevents ill-informed decision making. As a user experience practitioner, this is something our discipline is well versed in. Our experience shows us that the direct user contact is going to be the most valuable, and the further away you get, the worse the 'telephone game' effect becomes. This means, that while a UE/UX person may own the testing, it is critical that many members of the team participate so they experience the users' perspective first hand.
Building on that, I'm not sure I agree that there is no place in scrum for the BA (or the UE). Jeff Patton, one of the more eloquent educators on integrating UE and agile, describes product ownership as a team let by an individual. The responsibilities of the PM are to great to reside on one person alone. The BA and the UE are two partners in that team.
By
Jeremy Kriegel User Experience Practitioner; Blogger @ methodsansmadness.com
posted 5 days ago
(http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=23267795&gid=43421&trk=add-news-lnk-0Ot79xs2RVr6JBpnsJt7dBpSBA)
On a Scrum based project I worked on, our teams each had one or more BAs on them. They quickly fell into the role of Product Owner and User proxies -- they proved invaluable in helping the team understand the context around user stories, what the users really wanted, and what they would accept. They knew how to figure out not only what the business processes were, but *why* they existed in the first place. Not something you usually get with a bunch of developers and testers.
We never would have achieved the velocity we did without them.
The ten tips in your article are right on, by the way.
By Nathan Carpenter Chief Scientist at Pyxis Engineering
posted 20 days ago
Only registered users may post comments.
|