Each generation takes the best of the best and applies its own jargon to the title, related methodologies, policies, plans and processes. Each iteration is more collaborative with shorter and more iterations of its components. What varies in and between generations is the perserverance and genuine participation of the project stakeholders. The more the process is trusted, the more successful the project or program. Too often within or between generations, the respective "process" is not truly understood, the participants (stakeholders) not fully trained, and/or shortcuts are attempted (not doing or not doing fully what is to be done, not taking the necessary time, acceding to political or profit motivations and changing the project parameters). When allowed, properly trained people, properly resourced, are successful within any previously successful construct (repeatable methodology, plan, etc.). Agile, more than previous constructs, just emphasizes the increase in collaboration and iterations, and need to be able to produce subdeliverables while other subdeliverables and the main deliverable are still in flux. The difference, primarily between now and the past, is more of the team needs to be comfortable in the ambiguity of moving and constructing so quickly rather than just the leader(s). As that happens, more can be done more quickly. But as noted in the article, for some stakeholders, their specific roles may not change that significantly.
You can read more about my thoughts on the role of business analysts on Scrum projects here: http://www.romanpichler.com/blog/2010/03/business-analysts-in-scrum/
Good read by Roman! (his blog post, mentioned in the comment by him above).
Likewise, you can read more about my thoughts (my full answers to Jarett's questions in this two-part blog:
http://ebgconsulting.com/blog/how-agile-is-influencing-the-traditional-business-analyst-role-part-1/
and
http://ebgconsulting.com/blog/how-agile-is-influencing-the-traditional-business-analyst-role-part-2/
"the emphasis is clearly shifted to ensuring that the people who need to meet the requirements understand them rather than having a pristine document that may not effectively communicate the information to the implementers. "
Maybe I worked in a weird environment, but while we never worked "agile", the above was true. We tried to work effectively.
Also, as a BA I was always in contact with the developers, no "hand over", I was actually sitting with them from the start of the project to the end.
Common sense can be found outside of "agile" too.
I feel that you missed the most important task of a BA on Agile projects. Agile projects require an up-front big picture. This big picture is used to, among other things, scope the project and to prioritize the individual iterations. Coming up with this big picture (in a just enough fashion) is by far the most important thing that a BA needs to do on an agile project. Funny that none of the "experts" sees such.
Tony
Tony:
The article author wrote a high level summary of responses he obtained from each of the interviewees. Given limited space, he could not incorporate all ideas and comments that each of us must have shared with him.
My guess is that is why you don't see points any of us may have made about "the big picture".
As for me, this is a key issue -- the "big view" --which i did bring up in my response to the interview question.
On agile projects, requirements and planning converge.
i discussed the need to have that "up-front big picture" in my blog post (the 2 part post contains my complete responses to Jarett's questions).
You can find my comment toward the bottom of that blog post where it reads, "Agile presents special requirements challenges" at this location:
http://ebgconsulting.com/blog/how-agile-is-influencing-the-traditional-business-analyst-role-part-1/
and also in this article:
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1143/A-View-to-Agile-Requirements.aspx for more.
all the best,
~ ellen
After reading Ellen's excellent article "A View to Agile Requirements," you my want to check out my take on the big view / visioning work in Scrum:
http://www.romanpichler.com/blog/2010/02/envisioning-your-product/
If the visioning activities are carried out by the Scrum team, then a business analyst on the team would certainly be involved. The same is true if the business analyst plays the product owner role or if the individual is part of the product owner team.
Roman
Ellen:
Your past articles to the side, this article does not discuss what the most important contribution of a BA in an Agile project is: Coming up with a adequate (but just enough) big picture. And - especially in a high-level discussion - there should be a heavy focus on the most important thing that should be done.
The article mentions Cockburn as saying that Agile is a "priorities and values declaration..." So what are the BA responsibilities during an Agile project prioritized? The article mentions that Nee says that there is a need for BAs to gather requirements during the individual iterations, but the priority of that task is significantly lower than of that of coming up with the big picture.
Tony
Thanks everyone for the comments and to Ellen and Roman for their follow-up posts.
As Ellen mentioned I had a wealth of great responses from all the experts and could not incorporate all their details. Tony you are correct that I did not highlight the importance of having a clear initial scope in an Agile project, I apologize for this omission.
Personally, I don't believe that it necessarily falls to the BA to provide an up front picture. My belief is that the 'team' (not just the implementers but other stakeholders such as the sponsor or Product Owner) needs to come up with this picture collectively.
To place such a specific responsibility on one individual within an Agile project would tend to devolve people back into strict roles and responsibilities that could be a detriment the end goal, which is to deliver the best quality product or solution possible. What if a developer can articulate the big picture clearly? Or a tester? Or the manager who is ultimately repsonsible for the delivery of the solution? Should the BA insist on producing the document or descriptions for the product definition if there are others on the team who can do just as good of a job or better, because that's what BAs do?
While a BA likely has a good skill set to help guide the team to come up with the initial scope, but I would hesitate to prescribe that they are the sole person in a team who can perform this duty. If the picture is unclear or imprecise and the team is struggling to come up with a good description, then the BA should step up and help lead activities that will help the team come together on a good precise understanding of what needs to be done.
Only registered users may post comments.
|