The BA Times
A podcast talking about the role of a business analyst in the UK IT sector
The BA Times
The BA Times - Waterfall vs Agile from a Business Analyst perspective
Presenters
Neil Murphy: https://www.linkedin.com/in/neil-murphy-1613601/
Pete Bagnall: https://www.linkedin.com/in/petebagnall/
okay, pete, we are recording we're ready yeah let's do it.
Speaker 2:Episode two, episode two uh, hi everyone, welcome to the ba times podcast. My name is pete bagnell. I'm a business analyst. I've been a business analyst for 18 years, uh, predominantly in the finance sector, and I'm joined by my co-presenter, neil Murphy. Hi, neil.
Speaker 1:Hi Pete, hi everyone. Yeah, so my name's Neil Murphy. I've been BA a bit longer than Pete, so I'm probably hitting 23-24 years. I haven't never worked in finance, actually, so I've worked in pretty much most other sectors retail, transport, aviation, etc.
Speaker 2:Thanks, Neil. So yeah, just to set the scene for anyone that hasn't listened, our intention is for the podcast to have a really open, honest conversation about the BA role, the BA community, specifically in the UK market, Hopefully provide everyone that's listening with some insights and tips on just our experience in the BA role yeah, and the other thing we're going to do is give a 360 view of the BA role so coming up and over the next few episodes we're going to have guests coming on.
Speaker 1:So we've got some project managers lined up, product owner lined up and we've got some really good recruitment agents lined up. Give you insight into that whole recruitment process and what they look for in BAs.
Speaker 2:I think today what we're going to talk about is Waterfall versus Agile.
Speaker 1:The Agile classic conversation.
Speaker 2:I know Probably a topic that's been in every organisation probably in the last decade or so is do we go Waterfall, do we go agile or is there something in between? So, neil, I mean from your perspective, from when you started your career as a BA to now, I mean what's your experiences, I guess, specifically on waterfall? Let's start there, like how do you?
Speaker 1:Yeah, when I first started out as a BA, it was very much. You know you'd have to write a BRD business response document, business requirements document. That's it not business response document, business requirements document, possibly supported with a PRL prioritised requirements list, and that was quite arduous, you know, and it could be like 20, 30 pages worth of document and you know you'd go through version control 0.1, 0.1, 0.2, etc. And then also, speaking to people in the business, it was quite a cumbersome document to then sign off, you know, and then inevitably when you're in that waterfall environment you are going to have missed stuff etc. And really there, in theory, there is no capacity for that to be changed or, you know, additional scope added absolutely don't forget the old traceability matrix, that which would always accompany it all the giant spreadsheet of requirements and how they've changed and what they link to and everything else.
Speaker 2:And yeah, I think I'm the same. I think when I first started there was no other way of doing any software development specifically, I think it was always BRDs and all those artifacts that we've sort of mentioned, because that was just the way that everything was done.
Speaker 2:And then you just maybe, if you've done a project, that is, the shorter projects were not too bad if you had like a three or six month project, but they're fairly rare but if you're working on something for like a couple of years, years, you know that that requirement that you took on the 1st of January 2022, for example, by the time you get to June 2024, it's unlikely that that is still relevant.
Speaker 2:And then you go into the world of change requests and everything else. So I guess, from a BA perspective, it was very, very document heavy. It was very, yeah, just lots of documents, lots of change control and, like you say, until you really built that thing that you've described in your documents and you've given it to the people to hold it, you don't actually know whether you've captured every requirement. So I mean, you can see, I mean there must have been some positives to waterfall, I guess for other people in the teams, maybe, but for a ba it was definitely arduous I think I think probably positive from waterfall is uh, there'll be less nervousness from the business about what they're getting.
Speaker 1:You know that. I think when we move on to kind of talking a bit more about agile, one of the kind of key issues is trying to take business stakeholders on the journey. That, okay, in iteration one you're going to get x and y doesn't mean that in iteration two is going to be cancelled and you're not going to get your full uh system that you want. So I think that waterfall and actually for business users, is a bit more of a safety net and probably more assuring reassuring that you know they are going to get that system at the end of the software development.
Speaker 2:Yeah, absolutely, and I think that's like you say, that comfort blanket, especially for the more senior stakeholders. As you move up the line, above the sort of project managers and to the project sponsors, they get a very clear view, even though I guess in retrospect we say it was a clear view. But but any, I can't remember ever working on a project where you've done version one of your requirements document and it's all gone through the process and it's never been changed. So everyone costs out how much time it's going to take and how long and how much it's going to cost to deliver this project based on these requirements, but ultimately they ended up getting changed anyway. Um, so I think. But like you say, having that traceability I think helped, I guess, the more senior stakeholders and also the business, sort of just having a bit of comfort around it, I guess yeah.
Speaker 1:So I think if we move on to agile pete, we actually got introduced to agile at the same time, didn't we?
Speaker 2:we did. You actually introduced me to agile. I think you were the first person actually to ever show me and train me on agile. Believe it or not, you, you actually introduced me to Agile. I think you were the first person actually to ever show me and train me on Agile. Believe it or not. You actually taught me how to write user stories for one of our previous clients.
Speaker 1:So, yeah, I don't know how much experience you had at the time when you were telling me, I think it was probably about four months, five months wasn't it.
Speaker 1:Yeah, because I think you joined, yeah, probably about six months after I joined the client. And yeah, because I think you joined, yeah, probably about six months after I joined the client and yeah, so I thought you know that was a real learning curve, because I think that project we had multiple sprint teams, didn't we? Yeah, and we were I'd probably say that's the most agile project I've worked on Is it really?
Speaker 2:See, that's fascinating? Yeah, because I think it was pretty agile. So I guess, for a bit of context, we were developing a website in in the to keep it high level and not to name the client. But we're developing a website and I think, as a typical website is split into many functions and nil looked after a certain area. I looked after a certain area and, as nil said, we had a number of sprint teams developer sprint teams, designs developers, testers and, yeah, it was our first introduction to agile. But I do still feel, see, I think I've worked in more, I guess, crisp agile teams since then I still do feel that that team was still a little bit wagile or fragile, or you know these acronyms or whatever you get, where I think that we worked in an agile way, but everyone above us still needed a waterfall type output. As in, how long is everything going to take? I need dates and timelines on everything, even though, as you know, agile is not.
Speaker 1:You don't get everything up front yeah, and I think, um, you know we were working on two complex kind of software developments, weren't we? I was looking after online check-in and you were looking after the booking engine, and yeah, so it was a challenging project to get stuck into Agile, but I think overall it went well, didn't it?
Speaker 2:I think so. Yeah, I think it definitely did go well, I think it was a successful project and I think it was a good introduction to Agile. And I guess, from your perspective, I think for anyone that's listening that maybe hasn't come across Agile before, that is either an aspiring BA or just listening in general. How would you? I guess, what are the key differences between a waterfall project that we've explained, which is quite rigid, heavy documentation, everything up front before you move to each sort of stage gate, and then how does Agile compare to that?
Speaker 1:Agile's the Wild West yeah you're not wrong.
Speaker 1:No, no, in all seriousness, though, it's more around. We've talked about this user stories. So, you know, as a customer, I wish to log into my account, you know. And then it's around the acceptance criteria, around what email, you know, email format, password criteria, et cetera, and that's just one, that's a ticket, effectively, and then the dev would pick that up and then they would pass against it, et cetera. And so I think what Agile gives us, I think, is that kind of that kind of granularity, by able to understand, you know, you know, here you go, here's what password criteria is going to be, uh, whereas that would get lost in a brd. And actually, you know, you might take the part of the login story to your legal team on your it privacy security team and they might say well, hang on, you can't have a password that's only got four characters in it. You've got to have a minimum of 12 characters with, uh, you know, special, special character and a number yeah, and I think what you just touched on there is really another benefit.
Speaker 2:I guess, from a ba perspective, when you used to create a brd could be dozens and dozens, hundreds of pages long and you had to walk through the entire document with everybody. So designers, legal tone of voice, whoever you're going to speak to whereas I think a key thing you just said there is you can write a user story and actually you can just take the people that need to understand that user story through that user story, that they only need to be exposed to the areas that they are required to, rather than having to understand the full solution. And I think the key bit is just iterated as well. I think the real power for me for Agile, especially in the BA space, is that freedom that you don't have to get it 100% right first time. So you could write a user story on password security and actually that could be developed and that could be built.
Speaker 2:And then if someone comes along and says, actually you didn't say we needed a special character there, or you've said it's eight characters long, it needs to be 12 characters long, you can just write another user story and you replace that, rather than having going through the old brd process of, okay, now let's change the document, let's redo everything, and then it doesn't get built until everything is absolutely perfect. So I mean, for me at least, I think um agile is definitely more beneficial and a bit more flexible from the BA perspective, but I guess we have worked in slightly different industries. I mean, what's your take on user stories? How have you seen them written? Have you got a way that you write them? Or how do you typically pull it together, or is it pre-prescribed for you?
Speaker 1:It kind of varies between each client. I work with um, but what I don't do is go in there and go right, here we go, it's such a agile and then go, right, you should be writing user stories like this. You know what? Why are we not doing a release every two weeks? Why aren't we pushing you know functionality to the customer, etc. I think that's kind of one key thing I picked up on over the years when I've been having chats with potential clients and they see, you know I've got quite strong agile backgrounds they do kind of say, well, we're kind of fragile agile, you know, and they're kind of checking that I'm not an agile evangelist who's going to either try and compose my way of thinking on how user stories should be written or I'm going to go two weeks, three weeks into the contract and then walk away because it's not the pure environment that I want it to be.
Speaker 1:And I think you know I've worked in organizations where they've tried and prescribed for every project. Each project had to have the right story in the same way, et cetera. I've seen that. But I think really your key customers for your stories determine how you write the stories. So your key customers are business users to understand what functionality they're getting. So I've got that your tester or testing team so they know that they can look at it and go okay, you've missed out this scenario, whatever. And ultimately you know it is your lead dev, your lead tech person that will kind of say to you well, this is how I think you know, maybe split this story out. Or actually, you know why don't we merge these stories together?
Speaker 2:yeah, yeah I couldn't agree more, I think. I think that's key for any ba going into any organization is to go in fairly. I don't know if open-minded is the right way, but exactly you've said, try not to be that evangelist of. This is the way it must be done. Um, I've worked for a number of clients and they all want user stories written in a slightly different way. I don't think there's necessarily a wrong way. I think, exactly as you said, as long as your key stakeholders, the people that are signing off the ticket, understand it, your developers understand it, your testers understand it.
Speaker 2:For me, I've always just tried to follow that sort of invest structure of writing a user story, regardless of how they want me to write it, structure of writing a user story, regardless of how they want me to write it and regardless of whether it's a given, when, then, or however they want it done, because I've seen it done in so many different ways and actually, typically in finance, they will tell you this is exactly how you want to do it, this is how we want you to do it, this is the structure that we want it, these are the labels we want and everything. This is how you they're quite prescribed. Um, but I think if you follow that invest structure so for those that don't know, I guess the invest structure is it stands for independent, negotiable, valuable, estimatable, small and testable. So your, if your ticket can sort of follow those characteristics, typically it's a good, it's seen as a good ticket and then everyone can understand it and it's small enough to to iterate, put it into a little two-week sprint, um, so yeah, for me again, like yourself, I think being a ba, you have to be adaptable and I think we mentioned that in the last uh podcast is. I think that adaptability I think is is really key, I think, in my opinion.
Speaker 2:Um, but I think, once you've got your tickets and you've got sort of a set of user stories Three Amigos have you seen Three Amigos? Have you heard of Three Amigos? Do you use Three Amigos? I?
Speaker 1:love Three Amigos. I love Three Amigos I mean because you know when you look at Agile, you'll have your ceremonies, you'll have sprint planning, stand-up, retro demo, et cetera. You look at agile, you'll have your ceremonies, you'll have, you'll have sprint planning, stand up, retro demo, etc. And so those are the formalized kind of uh parts of agile. And what happened over the years is some people went okay, well, we need to.
Speaker 1:Stories are probably what we saw at a virgin. Stories go into sprint planning. And I remember one team who will remain nameless. They were in sprint planning for four hours as they rearranged all their stories and they were telling them to split them. Split these or put these together. And yes, I use three amigos all the time. So what three amigos is is basically me as a BA, I will get my test lead in and my tech lead in, and we will sit down and review the stories prior to sprint planning and go right, okay, are we all happy with these stories? And my tech lead might say to me break that down or actually take that out of sprint planning because we've got dependency on x and y, etc. And basically, what three amigos do with having the test lead and your tech lead. Looking at the stories, investing in them, I find you get away.
Speaker 1:You start to move from your requirements for our requirements yeah because those guys have looked at those stories, inputted into those stories and really then you know they're good to go.
Speaker 2:I mean, pete abused three amigos much yeah, all the time I think I don't, and that I think I'm just trying to think of any agile environment where I've been in, where I haven't used it. I don't think there's been one. I think it's a really important session to have. I think, exactly for the reasons that you've just said, you get that buy in from the key people within your scrum team or within your team and I think when you do then start going into like a sprint planning session, you those key people within the team, are aware and invested in those tickets. So when there are questions and challenges from the wider team who are maybe seeing those tickets for the first time, I think the fact that you've had input from your dev lead, your test lead, and you've been able to refine those tickets, I think that's a really good part of being a BA.
Speaker 2:I think for me that's sort of the enjoyable bit as well.
Speaker 2:You've got the business sort of coming in and saying, oh, we want to do all these things and you sort of break the tickets down as how best you see fit and then you really get that validation really from the testers and the engineers say, yeah, that's exactly what we would need and, like you say they'll pull some stuff out and say, can you split a story?
Speaker 2:So splitting a story might just be that you know what that story is. Just too big, because I mean typically, I mean I don't know how you found it, but sometimes I'll write a story and I'll be like this is the easiest story in the world, like this is going to be such a low estimate. This is dead simple. And there'll be other stories that I think are massively complicated and you put it in front of the engineers and it's the absolute opposite and they want things split up and done in different ways, you know, to make their life easier, which ultimately, I think from a BA perspective, my I think objective is always to give the business what they need, but to make the development process as easy as possible.
Speaker 1:Um, yeah if, if I can yeah, I mean, I've worked with tech teams that won't accept anything above a nine pointer. Yeah, that's a story you know, because in theory you can go. What was it?
Speaker 2:you can go three, six, nine, well one, one, two, three, five, eight, thirteen the fibonacci scale. So, yeah, I've had people that if it gets to 13 you have to split it. So eight is the maximum. So if you get to a 13 point story um, again for those people listening like it's based on complexity, everybody does it differently so we could have a whole session on story pointing. That's not one that I want to talk about, but effectively a 13 point story is very, very complicated. So the team would typically say, well, actually that's probably quite a big and complex story. Let's split that and you might end up with two eight point stories or an eight and a five point or whatever it might be. But, um, yeah, yeah, I don't want to talk anymore about story pointing because it's.
Speaker 2:And how do you think the ba role varies? I guess within different agile teams? You feel you always. I mean, we've mentioned a little bit there about sprint planning and other ceremonies that happen and even things like testing, like an uat testing or actual functional testing. Do you see the ba always sort of performing the same, or have you, as a ba, always perform the same role in an agile team, or have you seen it vary depending on the client you're working for?
Speaker 1:yeah, again, it varies depending on the client. You know some teams we've had. I've had scrum masters, product owners. Other times I've been probably acting as the scrum master slash product owner, you know. So, leading kind of, you know stand up, leading up, leading planning et cetera. And yeah, it just really depends on what that setup is, initial headcount is. And you know, yeah, testing is another thing.
Speaker 1:I think sometimes we're fortunate enough that you do have a test lead or a testing team that come in and do the vast majority of testing. Other times it's just me, you know, and I and also, again, that's one of the key things I think about being a ba is education, education, business, about user acceptance, testing. So ultimately, as much as I can say, the product is now working. I do need people in the business to test it because they will want, they'll pick up, pick out some random scenarios they see on a day-to-day basis that isn't in the test scripts and will go okay, well, if it's raining on a Friday, what does the system do, kind of thing. So you know it does vary. And again, I think when you're contracting you don't sort of say, well, sorry, I don't do testing, absolutely. I mean what your experience is like in finance, finance.
Speaker 2:I guess you've got quite a big team, something yeah, you say that it's very it can be really hit and miss. Um, it can be really hit and miss, I think. I think, as you say, that as a ba in an agile team you always seem you're always responsible for that sort of requirements tickets. There may or may not be a scrum master. I've seen teams where the scrum master is rotated, so there's not a scrum master in, and each sprint a different person is responsible for the scrum master activities, which not sure if I'm a fan of or not, but I've seen that happening as well. So you have to put sort of put that hat on, uh, and, like you say, sometimes you're sort of a pseudo product owner as well and feeding into some of the higher objectives.
Speaker 2:so actually, a lot, of, lot of the time there's people coming in and saying well, actually we've got this idea, how long is it going to take? Can you sort of take a different sort of role on? So, yeah, I think you have to like. I think, like we touched on before, you just can't be evangelist, if that's a word about the role. I think you have to go in with a fairly you know that your core function is to probably get those tickets written, but actually you might have to wear a number of other hats.
Speaker 2:And then on the testing, I think again, sometimes I've had situations where we've had a test team and they test, but they're actually expecting me to UAT, so I will do the UAT. And actually the first time the business see it is in a show and tell, so they're not even UATing it, they're just saying we've developed it. This is in a show and tell, so they're not even uat-ing it, they're just saying we've developed it, this is in the release and this is what it's going to look like. They've signed off the tickets and they've signed off everything. And again, that's a strange position to be in, because when you do it in the show and tell and then we don't like that well it goes into the next sprint.
Speaker 2:you know you have to redevelop and make the changes, so, um, but again you just have to sort of roll with. However, the structure of the team is in the organization and sometimes, I think an easy thing to forget as a BA is a lot of the time, especially in the companies that I've worked with they don't have dedicated resource just to help you from the business. They've all got day jobs, they've all got a nine to five that they are filling up with their day and we are just there trying to steal some time. So I think that's where you have to have a bit of empathy as well towards some of your stakeholders. I think, um, but yeah, I think that's my, my thoughts on it absolutely yeah, well, I think we'll wrap this one up, will we p?
Speaker 1:I think we probably covered what we were hoping to cover yeah, I think that's a.
Speaker 2:I mean, that's a high level. I think it gives a good. I think you can tell that we're probably more on the agile side of the train than the waterfall side of the train from the va perspective.
Speaker 1:So I think most, most companies are now, I think. So you know, yeah, you know. I think it'd be very, very unfortunate if I went into my next contract and they said, oh, can you write a 60 pagepage BRD.
Speaker 2:Yeah, and just to add before we close out, I think that is something that I've noticed. I think maybe five, 10 years ago you would see on a job description that you needed agile experience, whereas now it's assumed. I feel like it's not something that is called out now. I think companies have transitioned. I would say 90% of the companies that I look at now are working in an agile way and they just expect you to have that agile experience. So, yeah, I think that's it, but thanks everyone for listening. This is our second episode of the BA Times. You can find us on LinkedIn. The episodes are on Spotify, apple Podcasts, so please like share, send us any feedback, comments, any topics that you'd like us to cover.
Speaker 1:And yeah, we've been a bit slack on episodes at the moment for various reasons, but we are now going to pick up the pace a bit, so new episodes will be dropping regularly. Thanks a lot for listening, guys cheers now.
Speaker 2:Thanks all cheers.
