On November 17, 2020 I joined the Southeast Wisconsin Chapter of IIBA for an Ask Me Anything session focused on Business Analysis in an Agile World.
Here are the questions that came up during the session along with my answers.
I answered some of these questions during the session so these answers reflect what I would say having time to reflect and ponder.
Other questions I didn’t get a chance to answer during the session, so here’s my first pass at answering those.
Early Career
In our community, we have organizations that went through their agile transformation more than 10 years ago and are very mature. We have others that have done it very recently.
We have some that implemented in a home-grown, grass-roots fashion. While we have others who implemented in a very regimented – everyone does it the same way – fashion. What have you seen?
Yep, that sounds about right. There are several different ways that organizations attempt to adopt agile. I think there are two keys to success regardless of the approach that the organization takes.
First, everyone that’s impacted by the adoption of agile approaches understands WHY they are adopting agile. What problem are they hoping to solve by adopting agile.
Is the organization adopting agile because other organizations in their industry have all adopted agile? That’s rarely a compelling reason.
Is the organization adopting agile because they want to deliver things faster, better, cheaper? Be prepared to be disappointed unless you pair adopting agile with the willingness to make the tough decisions about what projects you do – and more importantly do not – take on.
Regardless of what some would have you believe, adopting agile by itself does not make you faster or cheaper. It may help you produce better products if you follow the good engineering practices that come as part of some agile frameworks.
Is your organization adopting agile in order to focus on outcomes and to instill a culture of learning and iteration? You’ll probably be more successful.
The second key to success is that the leaders in the organization support adopting agile and are willing to address issues that come to light as teams start working in an agile fashion.
As teams start working in an agile fashion, they are going to uncover a lot of organizational dysfunctions that people may have been aware of but concluded there’s not much that could be done about them. They also rely on an overbearing process to overcome (at least partially) those issues.
When you start working in an agile fashion, those obstacles become a bit more obvious and more impactful. If the people who are in a position to remove those obstacles aren’t willing to do so, the agile transformation won’t get very far.
See also: The secret to effective agile “transformations”
BA in Agile: Should we use a different title to help with defining our role?
It seems “BA” is so tied to waterfall, and maybe Product Analyst, or some other “Product” title may help bridge the gap.
I’ve found that organizations are going to use whatever terms they want to in order to refer to a particular role, even if you have industry wide organizations such as IIBA trying to bring some standardization.
At the end of the day, changing your title isn’t really going to define what you can do. Your actions and demonstrated results are going to help you do that much more effectively.
This excerpt from How to be an agile business analyst captures what I suggest you might try to provide a more meaningful definition of your role.
That said, business analysts are product people too, so I think there’s some validity to exploring product management roles. This exploration of product roles may be helpful as well.
What is your perspective on certification – IIBA, SCRUM, PMI, etc.?
See: Why you don’t need a certification to be an effective business analyst The TL;DR: If you think you need a certification, then get one. Just understand why.
From your experience what is the career roadmap you see for a Business Analyst in this Agile era?
See: The roles that product people play. I think that does a good job of describing where business analysis skills come in handy. Another potential not mentioned in that article is delivery lead or scrum master.
Which critical skills should a new Business Analyst have for a successful career?
- Communication skills (both written and verbal)
- Facilitation skills
- Ability to make sure decisions get made
- A healthy bit of skepticism to dig deeper and understand what’s really going on.
- Enough technical understanding to detect B.S.
And if you find yourself doing product ownership, you need to be DRIVEN.
Technical skills and Tools
Is there a BA skill gap between those who have worked exclusively in agile and never in a waterfall environment? Or vice versa?
If so, what have you seen? What have you advocated?
BA’s who have worked exclusively in agile may not be as familiar with techniques that really help you understand business processes, data, and business rules.
BA’s who have worked exclusively in waterfall may have a very narrow view of what their responsibilities are and may lack some collaboration and decision making skills.
In either case, the skill gap is not insurmountable as long as you’re open to continuous learning. Here are some thoughts on how you can build your own learning plan.
What is your opinion about “standard deliverables”?
Personally I prefer having documentation that fits the project to promote a shared understanding – but other BAs at my company want to talk about having “standard documentation”….
When it comes to documentation, I’d prefer to know about options I have to pick from and when each is applicable rather than having a required list of documents you have to fill out.
When you’re aware of a set of techniques that you have at your disposal and when each one is most helpful, you are much better prepared to build shared understanding in a whole host of situations.
When you have a required set of documents you have to fill out, those documents become items on a checklist and you rarely put any thought into why you’re filling out that document other than the process says so. The end result is you do a lot of extra work that’s not very valuable and are no further along in your shared understanding than when you started.
What are your favorite tools, especially in this exclusively virtual environment?
See: A product person’s guide to remote product teams.
Does eliciting requirements change when you are bound to working on a COTS application vs. building from scratch?
Yes and no.
In reality, it shouldn’t. In either case you should start out by understanding what problem you’re trying to solve (your outcome). Then you want to understand the constraints around a possible solution based on the interfaces that need to be considered and the processes you have to support. The description of what you do during discovery sessions can be helpful to understand all the elicitation techniques and activities you could do regardless of solution.
If you’ve explicitly made an informed buy vs build decision, then you may find elicitation may be a bit different as you do deep dive into the specifics of your solution.
If you’re implementing a COTS solution, you’ll probably be focused on interfaces, what configuration settings you need, and how you may need to revise work procedures to fit the tool your organization purchased.
If you’re building something from scratch, you’re diving into business processes, data (both interfaces and the specifics of what data you need to process) and business rules.
How can business analyst performance be measured for improvement in Agile Business Analysis?
Are you keeping your team focused on the outcome you’re trying to deliver? Does everyone have a shared understanding about that outcome and constraints on a solution? Are you making sure timely, informed decisions are getting made?
Then you’re performing well as an agile business analyst.
In other words, measure the performance of the team in delivering value, not the individual team members. The individual team members will be able to identify when someone is not carrying their weight.
Leadership
What is your response when an organization says there is no BA in agile?
If I’m feeling particularly pedantic I’ll say there are no roles specifically define “in agile” period. That’s partly because there is no single definition of what agile is. People usually refer to the Manifesto for Agile Software Development and the 12 Principles Behind the Agile Manifesto as the “definition” of agile. Do you see any roles explicitly excluded there?
And then I’d refer them to 7 Things business analysts need to know about agile, especially point #3.
Agile supports failing fast in the SDLC process. From your experience how an organization in its early stages of Agile transformation handles this? Do they stay on track or can easily go off track?
Referring back to my earlier discussion about why organizations adopt agile. If an organization does not have a clear understanding of why they are adopting agile, or if they do understand, but don’t think learning is part of that, they aren’t going to adapt well to the “Fail Fast” aspect of agile transformations.
If an organization doesn’t support teams experimenting, failing, and learning, the transformation will never stick.
How Business Analysis and Business Analysts contribute to a Project’s outcome vs. output?
See How to use outcomes to decide how to deliver a solution.
Does the Agile mindset work well for all businesses?
Yes. Especially if that business faces any sort of uncertainty. The key thing is to think of the agile mindset as focusing on outcomes and continuously learning.
What do you anticipate as the biggest future opportunities/challenges in the BA space?
For opportunities, see: The PM Role That Is On the Business Analysis Career Ladder.
For challenges, is that our actions do not convince people that Tom Smykowski is not, in fact, the prototypical BA.
Leave a Reply