What happens to the role of the Business Analyst in an Agile Utopia?

Featured
22108 Views
8 Comments
14 Likes

If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.

The Business Analyst in this context needs to be equipped with the full gambit of modeling strategies and tools with a heavy theoretical emphasis often speculating a distant outcome with very little to go on. Analysis under these conditions is a risky affair often resulting in hefty sign-off protocols ensuring that the business people are invited to become accomplices in the speculation game for the protection of all parties.

'As-is' and 'to-be' models are classic approaches to understanding the business change and maintaining organizational buy-in.

The dilemma with this is: What to do with the inherent risk?

Traditional BA's analyze the hell out of an endeavor before committing resources. The real issues only tend to become known towards the end of a project when precious little can be done about it.

Let's contrast this with a glimpse of what's in store for the development teams of the future...

I think its pretty safe to say Market Agility (i.e. responsiveness to the business environment) will increasingly prove to be the differentiating factor for most companies. The business analysts will need to get better at managing the dramatic increase in pace that comes with this. 

Agile development methods seem to be an obvious evolutionary step for our trade. Mainly aimed at restoring the team ethic, Agile (in the development sense) aims to promote development iterations, partnerships, collaboration, and process adaptability throughout the life-cycle of the project. Originating from the techie camp these methods are reaching ever increasing levels of popularity and to great effect... but the progress is slow and often fraught with growing pains as IT departments flex and bend in response.  

So what can the traditional Business Analyst do to adapt? 

Here's a recommended starter-for-ten:

  • Fight bureaucracy where-ever you can.

  • Restore the partnership ethic where ever possible.

  • Improve estimation (Look into Wideband Delphi principles)

  • Abandon theory based approaches and adopt an empirical approach.

  • Design experiments to answer difficult questions and resist the temptation to make ill informed decisions.

  • Embrace the unknown and make (or support) decisions based on observation.

  • Promote a risk based approach to testing.

  • Promote continuous improvement over state change philosophy.

  • Protect your objectivity. Represent the truth.

  • Promote the idea of stable, high performing, cross-functional teams (as opposed to silo'd temporary functional project teams).

  • Protect your credibility (DWYSYWD).

Business Analysts are uniquely equipped to provide powerful thought leadership to projects and many (if not all) of the tools we use can be applied to an Agile environment. Iterations demand that the analyst thinks faster, providing the business and project team with a continuous feedback signal of the real implications of decisions being made - only this time with a hell of a lot more time/resources to deal with the issues that arise.

In old-school projects I found myself spending the majority of my time building theoretical models partially tested on end users that would later be picked up by designers. In comparison, I found agile development or even projects managed under the Agile philosophy set promote an empirical approach and derive analysis through observation, experience, or experiment - leaving me with lots of time to develop those all-important relationships... This is fun to be part of not to mention very successful in satisfying stakeholders and producing valuable, high quality output. I can't wait for agile environments to become the norm as opposed to the exception.

I think Charles Darwin said it best:

"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."

The message seems clear: companies that fail to adapt will fail to survive.  I believe it falls to the Business Analysts to help set the agenda  and what better way to do this than by setting a compelling example for the rest to follow.

Author: Colart Miles is a seasoned Business Analyst with a passion for empowering organizational partnerships. Having delivered a number of highly successful projects including an award winning online business Colart has recently taken to evangelizing Agile methodologies (such as Scrum) with companies in London and New Zealand.  You can find more of Colart's writings on his blog at: badiaries.blogspot.com

Like this article:
  14 members liked this article
Featured
22108 Views
8 Comments
14 Likes

COMMENTS

Vasu posted on Monday, January 12, 2009 2:34 AM
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.
vasuramanujam
zarfman posted on Monday, January 12, 2009 4:27 PM
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
zarfman
george_pond posted on Tuesday, January 13, 2009 4:40 AM
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.


george_pond
Craig Brown posted on Saturday, January 17, 2009 5:16 AM
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.
craigwbrown
Harris Lloyd-Levy posted on Thursday, January 22, 2009 7:42 PM
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.
harris.lloydlevy
Colt posted on Wednesday, January 28, 2009 1:53 PM

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)
colart
Colt posted on Wednesday, January 28, 2009 1:56 PM

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)
colart
Colt posted on Wednesday, February 4, 2009 1:58 PM


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
colart
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC