The Experts’ Take on Business Analysis and Agile

Featured
70750 Views
9 Comments
106 Likes

If you ask Business Analysts what they think about ‘Agile’, you’re likely to get a mixed bag of answers. Some are curious about what Agile is, while others are interested or excited in the benefits of Agile methodologies. Some may have been on Agile projects and have seen dubious benefits, or have had great experiences.

In the past 2-3 years the term Agile has become increasingly prevalent in organizations of all shapes and sizes. While the Agile movement as a set of software development principles has been around for nearly 10 years, more and more Business Analysts are involved in ‘Agile teams’, ‘Agile projects’, ‘Agile organizations’, and are even becoming ‘Agile Business Analysts’.

With so many different ideas on what Agile is and how Agile impacts the Business Analysis profession, we decided to talk with leading experts in the Agile field and get their opinions on the subject. These people have been involved in Agile for several years (some prior to its formal inception) and have seen how individuals with traditional titles like Business Analyst or Project Manager fit into Agile teams. We received a great response from people who want to help Business Analysts understand how they can add value in an Agile environment. Our experts include:

What Does Agile Really Mean?

To get an understanding of what our experts meant when they talked about Agile, we asked them what the term Agile means to them. We received a variety of responses, which indicates how nebulous the term has become. Cockburn, Pichler and Gottesdiener all referred to the Agile Manifesto definition of the term, which is, as Cockburn notes, “is a priority- and values-declaration, not a methodology or process or tool.”

Others had a more general or varying viewpoint. Nee indicates that she believes that the term means “the adaptability to change. The tenets of Agile are about iterative, incremental delivery of the product within the project.” Ambler referred us to IBM Rational’s definition of the term .Pichler took a practical view and noted that in the software development environment Agile has become essentially a Scrum-driven activity. Kohl best summed it up: “Agile tends to mean whatever the speaker wants it to mean.  To deal with this, I ask a lot of questions about specific processes and tools to determine if they are using the word in the way I would.”

With no single specific definition it can be difficult for Business Analysts to understand what Agile means or how it affects their work. When a Business Analyst is being introduced to an ‘Agile’ environment or idea, it is best to follow Kohl’s suggestion and find out exactly what Agile means in the specific situation.

How the Business Analyst Role Changes in Agile

With the above variety of definitions of Agile in mind, we asked our experts how they saw the role of a Business Analyst within an Agile environment. The experts all agreed that from an actual job duty perspective the role of someone with the traditional title of a Business Analyst may not change that greatly. However, the format, techniques and even physical environment in which those tasks are performed can be drastically altered.

These shifts can occur because the needs and dynamics of an Agile team are different from a more traditional business or software development environment. Agile teams emphasize collaboration and ongoing engagement, whereas more traditional projects are focused on ‘phases’ and ‘hand-offs’ that can lead to the team segregating itself along job description or project phase lines.

One of the biggest changes a Business Analyst may experience is the timing of producing work products. For instance, Nee indicates that “the traditional BA will still be gathering requirements [but] in iterations, or increments, rather than all upfront.” Kohl believes that Business Analysts “no longer have a phase in which you do most of your analysis work, you do parts of it throughout the project.”

Another impact that Business Analysts may not be prepared for is the change in physical team dynamics. As Kohl indicates, “you also tend to work co-located with the rest of the team (goodbye office, hello open space) which can facilitate collaboration, but can also be noisy and distracting.” Business Analysts who haven’t been in ‘war-room’ type scenarios before may find this environment difficult to adjust to.

Article Pages

Page: 1 Of 4First  Previous  1  2  3  4  Next  Last  
Like this article:
  106 members liked this article
Featured
70750 Views
9 Comments
106 Likes

COMMENTS

DRN posted on Tuesday, March 9, 2010 10:45 AM
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.
romanpichler posted on Tuesday, March 9, 2010 12:39 PM
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/
ellengott posted on Tuesday, March 9, 2010 9:59 PM
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/

despil posted on Wednesday, March 10, 2010 8:51 AM
"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.
ajmarkos posted on Tuesday, March 16, 2010 9:42 AM
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
ellengott posted on Tuesday, March 16, 2010 11:17 AM
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
romanpichler posted on Tuesday, March 16, 2010 11:59 AM
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
ajmarkos posted on Tuesday, March 16, 2010 12:10 PM
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

larimar posted on Wednesday, March 17, 2010 9:04 AM
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.




Latest Articles


Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC