Business Analyst Community & Resources | Modern Analyst

The Experts’ Take on Business Analysis and Agile

Featured

127742 Views

9 Comments

2166 Likes

Conclusion: Business Analysts and Agile

As more organizations experiment with Agile, in all its various forms, Business Analysts may find that their typical roles and responsibilities change. While there is undoubtedly still the same work to be done, it may take on different forms and involve different people. Anyone who has been on several Agile projects to teams will tell you that few, if any, Agile teams operate exactly the same way, use the same processes, or follow the same standards. Each group determines the best mix of processes, documents, interactions and activities to service their customer.

As a result, Business Analysts need to be open to different ideas and opportunities within an Agile environment. If you’re stripped of your title or self-contained office, do not take it personally. If another team member starts writing down requirements don’t feel as if you’re devalued. The goal of an Agile team is to leverage everyone’s knowledge, experience and talents to the benefit of the customer. Work with the other team members to find how you can best contribute. Typically this will involve many traditional Business Analyst tasks, but don’t be surprised if you end up doing something you never thought you would do.

Business Analysts play an important role in any team, Agile or otherwise. As the world continues to find ways to deliver value in shorter timeframes with less cost, Business Analyst can continue to leverage their communication, business knowledge and analytical skills to meet the needs of their organization.

Author: Jarett Hailes is a Business Consultant with Larimar Consulting Inc. He has worked with large and small organizations in both the private and public sectors as a Business Analyst and Project Manager, and is also a Scrum Certified Product Owner and ScrumMaster. Jarett brings experience and expertise from a variety of industries ranging from mathematical modeling, technology commercialization, finance, law enforcement and education. For more information, visit http://www.larimarconsulting.com.

Agile Experts’ Bios

Ellen Gottesdiener

EBG Consulting, Inc. principal consultant and founder Ellen Gottesdiener is an internationally recognized facilitator, trainer, coach, speaker, and expert on requirements development, product chartering, retrospectives, and collaborative workshops. As an agile coach and trainer, Ellen has a passion for agile requirements and works with large, complex products and helps elicit just enough requirements to achieve iteration and product goals. Author of two acclaimed books, Ellen delivers training, facilitation, and consulting services globally; speaks at industry conferences; writes articles and tweets; and is an IIBA (BABOK) expert reviewer and contributor. Her free eNewsletter Success with Requirements offers practical guidance and news, and EBG’s web site provides a variety of useful practitioner resources.. Contact Ellen at [email protected], visit her blog posts at www.ebgconsulting.com, and read her tweets at twitter.com/ellengott.

Scott Ambler

Scott W. Ambler is the Practice Leader for Agile Development at IBM Corporation. He works in the IBM Methods group developing process materials and travels the world helping clients to understand and adopt software processes that are right for them. A prolific author, Scott has received awards for several books, including those focused on the Unified Process, agile software development, Unified Modeling Language, and development based on the CMM (Capability Maturity Model). A widely recognized expert on Agile Process, he is a regular speaker at international IT conferences and a senior contributing editor for Dr. Dobb’s Journal. Scott also writes the Agile Software Development at Scale blog on IBM DeveloperWorks.

Ken Schwaber

Ken Schwaber has been in software development for over 30 years, from bottle washer to cook, from waiter to manager. Ken started his career as an operating systems programmer. Ken developed Scrum with Jeff Sutherland, was a signatory to the Agile Manifesto, and founded the Agile Alliance, Scrum Alliance, and Scrum.org. Ken lives with his wife Christina in Lexington, Massachusetts.

Alistair Cockburn

Dr. Alistair Cockburn is an internationally renowned IT strategist, expert on agile development, use cases, process design, project management, and object-oriented design. He was voted one of the “The All-Time Top 150 i-Technology Heroes” in 2007, for his pioneering work in understanding use cases and for co-creating the agile software development movement. He is the author of the Crystal agile methodologies, three Jolt-awarded books on software development, the co-author of the Agile Manifesto and the project management Declaration of Interdependence, inventor of Initial Response Technique massage, and a Certified Scrum Trainer. He is known for his lively presentations and interactive workshops. His blog, poems, articles, and talks are available online at http://alistair.cockburn.us.

Roman Pichler

Roman Pichler is a leading Scrum and agile product management expert. He is the author of Agile Product Management with Scrum: Creating Products that Customers Love. Roman has a long track record in teaching and coaching product owners and in helping companies apply effective product management practices. Find out more at romanpichler.com.

Jonathan Kohl

Based in Calgary, Alberta, Canada, Jonathan Kohl is the founder and principal software consultant of Kohl Concepts, Inc. A noted software testing thinker and strategist, Jonathan is a natural investigator on software projects. In addition to assisting teams with testing, Jonathan helps companies define and implement their ideas into products, coaches practitioners as they develop software on teams, and works with leaders helping them define and implement their strategic vision. Jonathan is also a popular author and speaker. His blog on software development and testing issues is one of the most well-read testing blogs in the industry. Jonathan doesn’t just write about and talk about developing software, he actively helps teams deliver the best products they can. Contact Jonathan at http://www.kohl.ca/.

Nancy Nee

Nancy Y. Nee, PMP, CBAP, CSM is Executive Director, Project Management & Business Analysis Programs at ESI International. Nancy has more than 15 years’ experience in the consulting industry, specializing in management consulting, project management, business analysis, IT, continuous process improvement and organizational change management for the private, public, and non-profit sectors. She is skilled in aligning and defining the strategic enterprise architecture, developing project governance and selection frameworks, analyzing business processes to apply knowledge to improve organizational efficiency, and implementing automated solutions. She has provided PM and BA training and consulting services globally on PM and BA principles and practices to numerous Fortune 500 companies. Nancy has been a speaker at conferences around the world, including PMI® Global Congress, ProjectWorld/World Congress for Business Analysts and numerous IIBA® and PMI® events

Article Pages

Page: 4 Of 4

First Previous 1 2 3 4 Next Last

Posted in: Leadership & Management, Career as a Business Systems Analyst, Agile Methods

2166 members liked this article

Featured

127742 Views

9 Comments

2166 Likes

Fostering Continuous Learning and Growth Through Reflective Practices in Software Teams

The Physics of Business Analysis: Applying Scientific Principles for Strategic Excellence

Top 10 Business Analysis Trends to Watch in 2025

Shared Accountability in Software Teams

COMMENTS

Dennis 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.

Roman Pichler 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/

Ellen Gottesdiener 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/

Roland Hesz 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.

Tony Markos 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

Ellen Gottesdiener 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

Roman Pichler 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

Tony Markos 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

Jarett Hailes 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.