On June 30th I recorded a webinar with Adrian Reed for Blackmetric Business Solutions. It was a wide ranging discussion driven by questions from the audience around all things business analysis and agile.
Here’s a recording of the session. You can find more information about the session on Adrian’s site.
Here are the questions that came up during the webinar. Where I answered the question during the webinar, I paraphrased the answer from the transcript (with some occasional embellishment).
If you have any follow up questions, note them in the comments or reach out directly.
What are the most important skills that a brand new BA should develop? What courses would you recommend?
During the webinar I highlighted the importance of communication skills. If you consider my defining characteristics of an agile business analyst:
- Consider context
- Focus your team on realizing maximum outcome with minimum output
- Build shared understanding
- Make sure decisions get made
- Use short feedback cycles to learn
They all have a lot to do with communication.
Communication becomes even more important when you work in a remote setting which I think it’s safe to say that most of us are doing now, and will be doing for the foreseeable future.
It’s more than just the verbal communications skills at that point. You also need to know which communication mechanism to use for any given situation. You can’t, and you shouldn’t, rely on meetings for all of your communication, just like you can’t rely on documentation for all of your communication. There’s definitely a balance.
In some cases, like when you need to convey a lot of information but there’s not a need for heavy discussion about it, you may find that a write up is sufficient. What you don’t want to do in these cases is call a meeting just to tell people a bunch of stuff without much interaction.
On the other hand, when you need to make sure that everyone has a shared understanding, your going to want to have an interactive conversation, but you’ll probably also find that having a written starting point can be very helpful.I ran across the one page/one hour pledge after the webinar that looks like it may be useful as a starting point for conversations to build a shared understanding. The premise is that whenever you have a document that you need to share with your team, limit yourself to spending an hour putting it to together and keeping it to one page. You’ll make something that is incomplete by design that forces you to have a conversation with your team in order to build shared understanding.
But I sense that just saying communication may have been necessary but insufficient. So I figured I’d suggest some techniques that I use repeatedly. The links for each of these go to technique briefs on my site that explain each in more detail.
- The problem statement to gain shared understanding about the problem you’re trying to solve.
- The context diagram to identify the important interfaces your product has and the key stakeholders you’ll need to interact with.
- Process models to make sure you understand the process you’re trying to support.
- Socratic questioning to make sure you’re asking the right questions in the right way.
The original question was also looking for classes I would suggest. I put together a course on Analysis Techniques for Product Owners which covers some of the techniques I mentioned above as well as several others and explain where those techniques come in handy, why you should use them, and how to make them work.
Which is the one most important skill that an Agile Business Analyst needs to possess within a Scrum team compared to operating in a traditional waterfall project team?
If your team is serious about operating in an agile manner, then you’re going to find yourself doing small bits of analysis throughout your work on a product rather than trying to do all the analysis at the beginning like you would have in a phase based approach.
To make that work, you’re going to have to be comfortable with uncertainty and be willing to do a little bit of work, get feedback, and revise your approach according to that feedback. In other words, use short feedback cycles to learn.
Can a business analyst be a product owner on a project team?
For the reasoning behind that answer, I’ll point you to this post on the roles product people play.
Why are people so “precious” about role titles and the techniques/approaches that are used within those roles…?
I think it’s partly trying to justify their existence, it’s partly different communities feeling the need to call the same thing by different names so that they can own it.
That’s why Scrum has product owners even though the term product manager already existed.
…Isn’t there just a shared pool of techniques/approaches that are used by many roles (such as Project Manager, BA, Product Owner, Systems Engineer etc.) Each of those roles probably has a few elements that are unique to them; but many elements are shared by several different disciplines.
Yep. I’ve written up the techniques I use most often in Technique Briefs.
What is the role of a Business Analyst in an agile team? I was asked this question during an interview
I’m not sure that’s an example of a good interview question. Likely they were trying to get a feel for your understanding about the intersection of agile and business analysis. A more effective way to test your knowledge is to ask you if you’ve encountered particular scenarios and how you addressed those scenarios.
So if you get that question again, instead of giving an academic answer, you may want to tell a story using the PEARL framework.
If I were answering that question in that way, I’d tell a story about how I exhibited the characteristics I mentioned earlier:
- Consider context
- Focus your team on realizing maximum outcome with minimum output
- Build shared understanding
- Make sure decisions get made
- Use short feedback cycles to learn
What is the role of the BA in relation to business analytics?
It probably would help to start with what we mean when we talk about business analytics. Here’s one definition: “Business analytics is the process of collating, sorting, processing, and studying business data, and using statistical models and iterative methodologies to transform data into business insights.”
One of the things business analysts do is understand the data that businesses need to achieve specific outcomes, business analytics is focused on using that data to help the business make decisions.
The two BA’s are definitely complimentary, and I’ve always thought the ability to deal with data is good skill for business analysts.
Kent I really liked your book “Beyond Requirements” (I already mentioned you a few times on Twitter… 🙂 ) can you say that BA role is related to Discovery and Deliver (maybe more about its role in a team)… or a BA role can still has a place in a more strategic side?
Glad that you liked Beyond Requirements and thanks for the mentions on Twitter!
The BA role is related to Discovery and Delivery, in fact I spoke to that a little bit in Beyond Requirements and posted that excerpt as a blog post. The TLDR: is that the product people working on a product typically are more focused in Discovery and support Delivery, but they are involved in both.
Along with that business analysts can certainly still have a place in the more strategic side, but that usually comes down to what other product people may be involved in and how you’ve split up responsibilities.
Frameworks and Methodologies
Is Agile a methodology?
The branded ways to approach your work in an agile manner such as Scrum and Extreme Programming are frameworks. They are a collection of practices and techniques that someone, somewhere found worked good for them in their context. They then packaged those techniques up and suggested them to other people.
Wrap it all up with training classes and certifications, and voila, you’ve just jumped on the agile process gravy train.
Methodologies describe the way a particular team chooses to work based on their situation and their context.
That’s how Alistair Cockburn described them once, and I find that distinction fairly useful.
What’s Kent’s view on the coexistence of Agile, Waterfall, DevOps methodologies in organisations and how we as BAs can effectively challenge the associated tensions which often manifest as a result?
Here’s a paraphrase of what I said during the webinar. I think I can stand by that,
I feel like sometimes I need to double check my understanding of DevOps because I hear people contrasting agile and DevOps and I’ve always just wondered why that was the case.
As I understand it, DevOps embodies a lot of the same ideas as agile does. DevOps focuses on the fact that for the longest time, the people that developed products and the people that were responsible for operating and releasing the products weren’t necessarily the same. And what’s worse, those two groups didn’t really get along very well together.
So DevOps was created primarily to say “Hey everybody, you should all work better together.”
DevOps basically brings back a focus on good technical practices back to agile.
In fact, when I was the chair of Agile 2013 we made a concerted effort to bring in more DevOps related content into the conference at that point in time because it was just starting to happen and get new. So those two definitely fit well together.
When you have an organization that wants to do a mixture of waterfall and agile, that’s a sign that the organization in question doesn’t share my understanding of what agile is.
It’s an indication they view agile as a methodology rather than a way of approaching work.
Rather than asking “should we do this project agile or waterfall?” it’s better to ask “what context are we operating in? What’s a good way for us to try things out, learn from it and adjust and what are the constraints we’re facing?”
You may find that there are certain aspects of a phased delivery that make sense in some circumstances.
Even if you do decide that you want to pick up some aspects of a phase based approach I hope you challenge one of the key underlying assumptions inherent in the waterfall approach – that it’s possible to figure out everything you need to know up front and then you can just go build it. When you’re working on software, or a business process you’re inevitably going to learn things along the way, and there is no point in trying to nail everything down right at the beginning.
So if you’ve got an organization having this whole big process to decide “do we want to do agile or waterfall?” I would check their understanding of what agile is. Basically, I think that’s the wrong question.
One tool that I’ve found helpful for determining your approach based on the risk factors of a project is the Context Leadership Model. It describes some risk factors you can use to assess your project and then provides guidance on the type of approach you should take based on your assessment. Plus, it has cute barn animals.
I keep hearing Kanban referred to as an Agile methodology. I’m confused as I thought it was a planning tool from Lean Six Sigma! (Within my organization, it’s sometimes used for planning within Scrum.) Please can you clarify. Thanks 🙂
David Anderson, who is one of the people who originally suggested using Kanban for software development would probably cringe if he heard people saying that.
I’ll refer you to a definition of Kanban I wrote for the Agile Glossary on AgileAlliance.org: “The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limit work in progress (WIP) and stop starting and start finishing.”
Of course it doesn’t really matter if it’s agile methodology or not. What’s important is whether you can get some use out of it in your situation.
I have found great value in applying the idea of single piece flow. It allows the team I’m working with to adjust what we work on next quicker than once every two weeks so we’re much more responsive to changes in the environment.
Software Development Life Cycle? There wasn’t much context around this question, so that’s about the best I could do.
Of course as Richard Feynman observed, knowing the name of something is not the same thing as knowing something.
How can a BA be part of Technical/micro service oriented scrum where product owner does not have any control on Product Backlog?
I answered this question during the webinar, but looking at the first part of the question again, I do want to add a comment that I didn’t get around to during the webinar.
If a product owner does not have any control over the product backlog, they are not going to be an effective product owner. Given the context described, I suspect that it’s a case of having the wrong person trying to do product ownership. See my example below for a bit more insight:
Ok, here’s the paraphrase of my answer from the webinar:
I haven’t personally been in that situation, but I did coach a fairly large product team that had a similar circumstance.
This team had around 40 or so teams spread across four different locations. They were organized into teams that focused on strictly customer facing functionality and other teams that worked on aspects of the underlying platform. Those platform teams are the ones that mirror the situation in the question.
The people who did product ownership on the platform teams ended up being architects. The organization went that route because the product owners for the platform teams needed to make the decisions about what platform services they needed to provide to these other teams in order to make sure they could properly support the customer facing functionality.
Having architects perform product ownership for those teams made sure that you had people with the proper knowledge making priority decisions and they were able to determine what technical capabilities they needed to provide.
I should note that those teams did not have business analysts, but there may have been a need for some form of business analysis to understand how the needs of the final customers translate into what kind of technical underpinnings they needed to provide.
So if I found myself in the situation I would explore
- Is there any tie (be it direct or indirect) between what this team is doing to what our ultimate customers are looking for?
- Do these teams have a shared understanding about the outcomes are they looking for? What are they trying to accomplish at the end of the day with that product? And how does that translate into what we need to do from a services standpoint
If the teams have a good handle on those two things and there is someone else who is more familiar with the technical aspects of the product, I’d probably suggest that they should do the product ownership for those platform teams and I would look to see if there were other teams I could help, or see if it makes sense for me to focus on the product as a whole. I’m assuming here that the product is large enough that there are multiple teams working on it.
It may also be the case that I’d find a different product to work with.
Maybe there’s another team where my skillset and viewpoint would add more value.
Sometimes there’s going to be places where the unique skill sets of business analysts aren’t quite as necessary, unless you’ve also got a lot of good technical chops.
Can agile methodology be applied to system migration projects? What are the key activities for the BA in this type of project?
I presume by “system migration” you mean moving from one system to a different one that is already built. Say between two Commercial Off the Shelf (COTS) systems.
Sure, you can do that in an agile manner. You would most likely iterate through the different sets of data that you have to transfer, the interfaces you have to change, and the business processes you have to revise. You transfer a little bit of data, you learn from what happened and you adjust your approach for the remaining data sets.
The key activities for a business analyst in this situation are fairly similar to any other efforts. You’re trying to understand the key data, business processes and rules that you need to support and then you’re understanding what differences exist between the old system and the new system.
If you’d like a deeper answer, reach out to me with more specifics and I’d be happy to talk through it with you.
How do you work Agile as a BA when a third party involved in a change requests all the requirements for development on their side up front?
Remember when I talked earlier about if someone buys into the assumption that you can figure everything out up front that’s a sign they don’t really understand agile?
That seems to be describing your third party.
Of course, the ultimate goal is not to get your third party to understand agile. The ultimate goal is to successfully make the change and get to your desired outcome.
I would start out by having an upfront, honest (dare I say “blunt”) conversation with your third party that it’s just not practical to have all requirements down to the most minute level defined up front. Seek to understand why they need this clarity and try to come to an agreement about what is the minimum you do need to have identified ahead of time and where you can have flexibility.
The third party may be willing to work with you and flex their approach, in which case you’ll probably be able to come to an agreement that will work (but one that you’ll probably need to revisit and revise on a regular basis).
Or, your third party will be adamant that they need everything clearly defined up front, and will use every change that happens because you learned something as an excuse to change the timeline or increase the cost. It’s better to find that out early and decide if this is the third party that you want to work with (if you have a choice) or if you should find a different third party.
If the situation is such that you can’t swap out the third party, then you’ll probably need to be prepared to go through a set of painful change request processes throughout the course of the effort. You may decide to change the sequence of work on your side to do all the things you need to do to get clarity about what you need from the third party and only then set down specifically what they need to do. If this is the case, make sure that your stakeholders are aware that your third party’s inflexibility is introducing risks to cost and timelines.
Gaining Agile Experience
I’m a PM who migrated to being a BA under a Waterfall with sprints and stories environment in an agency. Now looking for a new role preferably client-side/public sector – moving away from marketing. My main barrier to employment is ‘agile experience’ – any suggestions on how to get around that?
I answered this question during the webinar as well. Here’s my refined answer.
Let me start by saying I’m glad that you’re asking about how to get experience rather than “will certification get me there?” A certification can never substitute for experience, and in fact a truly meaningful certificate should also rely on you having experience. (Funny that most agile certificates don’t really have an experience component)
There’s a couple of different ways you get experience.
If you’re in an organization now, see if there’s any opportunities there to – if nothing else – insert agile practices, guerrilla style in your work that you’re doing now.
If you don’t have the opportunity to start using agile in a job that you’re in right now, then see if you can find a volunteer opportunity or a side gig where you can apply agile techniques.
That side gig could be starting a website or blog. Even if you just use WordPress, the act of going through and tweaking the settings can be a great way to get some experience applying the idea of getting feedback through short cycles and iterative development. Adrian also suggested that you could volunteer for your local IIBA chapter to help maintain their website.
And then when you’re talking to the people that you’re interviewing with, don’t necessarily just go out and say, “Hey, I’ve done agile” because everybody does that.
I’ve gotten to the point now where I can tell where people haven’t really had, what I would refer to as, as an actual experience working in an iterative fashion and using feedback to learn because they throw all the buzzwords out there, but they really can’t describe it.
But if you’re able to actually talk through what you did, how that helped you and your team to get outcomes and how you were able to cycle through things and learn from it, that’s very powerful.
If you’re able to explain that and why that helped you and how you would apply that to the situation of building a product or an internal application, I think that will go a long way with interviewers.
The People side of agile
(I’ll admit this is a little bit of a stretch in categorization, but hopefully when you read my answers it kind of makes sense that I grouped these together.)
How inclusive do you think Agile Scrum is? How can we ensure that introverts or reflectors are not disadvantaged by all the ceremonies?
I’ll paraphrase my answer from the webinar for this one.
I’m an introvert, so I pay close attention to this particular subject.
As long as you have facilitators on your team that are worth their salt – generally a scrum master, agile coach, or delivery lead – they should look for ways to encourage everybody to be engaged to the extent they’re comfortable.
If you are in a position where you are that facilitator, you need to make sure you understand everyone’s preferred level of interaction.
I find myself in that role quite a bit, and it’s a matter of getting to understand your team members’ preferences and to know the tells they have. Most introverts have some way of subconsciously conveying that they’re pondering or thinking of something. These types of tells initially are best trying to pick it up when you’re able to see them in person.
When it comes to the team I work with now, I’ve been able to pick up when people are pondering something even if we’re not in the same room. We’re generally on an open voice channel all day, so when we’re having discussions I’ve come to learn everyone’s habits about thinking about things. I do occasionally reach out and say, “Hey, just checking Adrian, what do you think about that?” if they haven’t spoken up in awhile.
When facilitated properly all the ceremonies can work very well with extroverts and introverts. You do need to balance not doing the ceremonies for ceremonies sake. I make it a point to keep official meetings to a bare minimum and as focused as possible.
Even though we’re a collaborative team you need to allow people the space to get into flow. I’m very conscientious about protecting people’s focus times and only have official discussions when we need to.
For a new business analyst who is the only one who is interested in the agile methodology in my organisation, how do I introduce this and make this the culture of my organisation?
I’ll paraphrase my answer from the webinar for this one.
I was that business analyst who was the only one in my organization interested in agile. It was 2004.
I worked in the information management area of a health insurance company. At the time (and still perhaps today) data warehousing areas were infamously not interested in anything that’s iterative or incremental or agile or anywhere close to it.
I was walking around a Barnes and Noble book store and saw a copy of Scott Ambler’s Agile Modeling book sitting on the discount table. I picked it up and looked through it and thought “wow, this sounds a lot like how I like to work”.
So I bought it, read it, and then started trying to introduce some of the techniques in the project I was working on.
The mistake I made was to announce that I was trying to be agile, and started extolling the benefits before fully understanding what they were. Needless to say, I got a bit of resistance to spreading the ideas past the team I was working with, but at least we were able to use many of the practices.
What I learned from that is when you find yourself in this situation, introduce agile principles and techniques in a guerrilla fashion.
Start behaving in an agile manner.
Look for the techniques that would work in particular situations and just try them out.
Don’t say you’re doing agile.
Don’t say you’re doing scrum.
And banish the phrases “that’s not agile!” or “if you’re not doing x, you’re not doing scrum!” from your repertoire.
It doesn’t matter if something is agile or whether you’re doing scrum. It matters if you’re being effective. Plus, if you’re introducing things in an agile fashion, no one really cares if something is agile or not.
Just say, “Hey, you know, we’ve got this particular problem we’re facing, why don’t we try this out and see how it works?” And then if it goes well and people ask you afterwards, “well, how’d you do that?” Then you say, “well, let me tell you, there’s this technique and this approach we used, and this is why I picked it. And here’s why it worked in this particular situation.”
I’ve found you’re going to have a lot more success if you demonstrate how agile approaches can work, and not be dogmatic about it.
Just say, “well, in this particular problem, this is how we did it. And this is the result we got.”
People will usually say, “Oh, I want me some of that. Let’s get some of that going here.”
How to increase the buy-in from key stakeholders?
Be pragmatic, not dogmatic.
Explain why it is to their benefit and the organization’s benefit to work in a different way.
Kent talked about the importance of learning in agile and adjusting your approach in the light of that learning. In relation to the product and what it does, effective learning can take time in my view/experience (people/organisation’s first reaction to something is not alway how they feel about it after using it for a while). Any thoughts about this and whether and how to include this time in an agile project
Here’s my answer from the webinar:
I’ve been working on an internal product for a year now. It’s for an internal audience of two people and has a lot of complex business logic involved. The product is replacing an existing product that these two users have been using for 20 years.
We found out that you can do demos every two weeks until you’re blue in the face, but you really don’t get meaningful feedback until your users actually start using your product in their day to day jobs.
The best thing you can do is to figure out how to get your users something fairly quickly so that they can start using it in real life.
You’ll find you can get users to come to your sprint reviews, watch the demo and maybe ask a question or two. They might even say they’ll try the product out a bit on their own. Chances are they won’t or they don’t find much stuff.
Get them to use the product in a safe to fail manner, and you’ll get a lot more feedback.
So try and figure out a way to get them start getting you users to use the product as soon as possible and allow some time to make revisions and corrections based on what you uncover.
I’m not suggesting that you shouldn’t involve your users in design discussions, demos, or trying things out ahead of time. You definitely should do that.
You just need to be prepared to get more meaningful feedback once they actually use the product.
Techniques and artifacts
What requirements artefacts would you expect to see within Agile? When I did BCS certificate in Systems Development Essentials, it suggested user stories are the highest level and documented requirements sit beneath them but I don’t know whether this often happens in practice.
I’d expect to see whatever artifacts serve a purpose. (And that purpose is not to check a box in some list of required artifacts).
Requirements artifacts are best suited to help you build shared understanding with the product team.
You can use that understanding of the big picture to identify your backlog items, then you specifically use acceptance criteria, models, and examples to further flesh out those backlog items.
The key to remember is: know what requirements artifacts are helpful for, and use them for that purpose.
What are your thoughts on BAs using agile techniques to develop ‘traditional’ artefacts, e.g. business processes, while working on a waterfall project?
Requirements artifacts are much better suited as aids to communication and building shared understanding rather than as the only means of trying to do those two things.
So if you have a choice of spending a lot of time to write artifacts out by yourself, or creating those artifacts collaboratively (whether it be on a real, or virtual, whiteboard) go the collaborative route. That will increase your odds of building the kind of shared understanding you’re looking for.
Of course you may find that you can increase the effectiveness of those collaborations by doing a bit of work ahead of time. If you do, keep in mind the one page/one hour pledge.
What are your views on the gherkin syntax?
Here’s generally what I said during the webinar.
If you’re not familiar with Gherkin, it’s not a pickle, it’s the technique of explain backlog items in a GIVEN, WHEN, THEN format. Typically it’s used to create acceptance tests, or it’s used to further explain acceptance criteria for a backlog item.
I think the format can be helpful. I think identifying examples to help bring clarity to backlog items is extremely powerful.
I have run across some teams that feel the need to require people to put everything into a Gherkin format, even going as far as expressing their backlog items in terms of Gherkin.
I don’t go that far.
Gherkin can be helpful to explain fairly complicated complex business logic. So I’ll certainly use Gherkin to explain process logic; basically pre conditions, and event happens, post conditions.
If I’m working on a business rule that has several different inputs to it and certain outputs, I’m going to use a tabular format instead.
The thing to remember with examples is not: “you always should use X particular format.” It’s basically: “here’s a selection of things we could use. Let’s figure out what works best for our team to use. And then we’ll do that.”
With the team I work with right now, if there is some complex business logic that I need to convey, I will switch over to using that format. But don’t always do it.
Sometimes it’s a judgment thing to say when should we use it, When should we not?
I should also note that the team does do automated acceptance testing and uses a tool called SpecFlow that basically requires things to be in the GIVEN WHEN THEN structure
Even if you’re not doing automated acceptance testing (though you really should) you can still use the idea of GIVEN WHEN THEN to talk through different scenarios and make sure you have everything covered.
This approach is often called Example Mapping. It’s a conversation that helps you discuss what possible solutions could exist and what you’d like to do in every situation.
Here’s a couple of other good resources I’d suggest on Gherkin and examples:
Given When Then Style Challenge from SpecFlow and Gojko Adzic
Specification by Example by Gojko Adzic
The thing about requirements gathering is about doing the refinement at “the last responsible moment”, just-in-time… what are the best ways to know when that is?
I find it helpful to establish an agreement amongst the team as to what information the team needs to know in order to start development work on a backlog item. We usually encapsulate that agreement in a definition of ready.
The most helpful part of that definition of ready is the discussion you have about the information you need, and the willingness to revise that understanding based on experience.
On the teams where I’ve used the definition of ready, I get value out of hearing what the team thinks they need in order to get started work on a backlog item. Then it’s a handy thing to refer back to when we need to revise our agreements.
The definition of ready should not be used as a club to force people to do things or an excuse to not start something if everything’s not there. In addition, you have to apply some pragmatism to individual backlog items. Not every backlog item requires the same information.
One of the main failure points where waterfall wins over agile is effort estimates: Execs need detailed plans with FTE laid out etc. whereas agile teams are saying we’ll get there when we get there and getting effort estimates takes considerable resource in itself. How do you resolve that?
I wouldn’t hold up the waterfall approach as a paragon for flawless estimating mainly because estimates done in a waterfall paradigm are flat out lies. They are based on the flawed assumption I mentioned earlier that you can actually know everything up front. Those detailed plans with FTE laid out convey a false sense of certainty that really doesn’t exist.
On the other hand, agile teams don’t do themselves any favors when they say “we’ll get there when we get there.” What they should say is “we can’t tell you exactly what’s going to be ready by when.”
All that said, people who are making decisions do need to have some information in order to make decisions about whether to undertake new work.
The answer is to change the question. First, understand why executives need estimates. What do they hope to do with that information? Usually, it’s to decide whether to start, continue, or kill an initiative.
Since you can’t know how long a software development activity will take when you start out, you should instead ask “how much is it worth to you?” Are you willing to spend 3 months, 6 months, a year to solve that problem? And then define what that solved problem looks like.
So you can save a lot of fruitless time estimating by defining the outcome in terms of the problem to solve, and then constrain the time in which you want to solve that problem and the money that you’re willing to spend to solve it.
You define scope in broad terms and give the team flexibility to define specific scope as they proceed through the effort and learn new things.
Here’s a little bit more on dealing with estimates for your reading pleasure.