Best Practise in the Agile World (7,134 words)
Vijay Nair (TP-MBA)
Guiding retail and telco companies through successful business transformations, I bring a strategic vision and approach to deliver tangible customer value. Let's connect and explore how to elevate your business.
This article is a transcript of the BA Video Series Linkedin Live video on Best Practises in the Agile World
You can also listen to this via our podcast
If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com
Speakers:
Intro
Good morning, LinkedIn, and welcome to this session on the BA video series. So our topic for today is best practices, in the agile world.We start with a quick introduction from our panelists, who share their project experiences related to the topic of the day.
Which today is best practices in the agile world. And we'll then conclude the session with a Q and a, from our viewers by the comments posted within the comments box. So two of you as, if you haven't already please sign up as a member of our BA video series, LinkedIn group. To watch our past LinkedIn live recordings on various business analysis topics.
I'm currently the head of the training business for a multinational silicone vendor. in my time I've been a project manager, a program manager, a scrum master product owner. So I've got a little bit of experience. I'm happy to share here on agile success or in some cases, maybe not.
And this is what I've been bought and a model where I come from a banking, from my past, exposure. Brilliant. Thanks a lot arena. Thank you. so before we kick off, then I just wanted to give a bit of a background to agile. What is agile? I know it's quite a buzzword in the industry. You know, we are agile and we have agile principles.
so I was looking for a definition and the best one I've found was actually on the agile Alliance website, which says agile within software development. It's. More than just a framework. It's more than a set of practices. It's more of an umbrella term for a set of frameworks and best practices and values expressed in the manifesto for agile software development.
So that for me is quite a long worded definition. and there's quite a few of you break that sentence down. It consists of a lot of things. So we've got a set of frameworks within that, a set of practices and also following the agile manifesto for software development. So I think it's key for organizations when they're thinking about agile is more than just a way of working.
It encompasses a lot of things. It's a set of frameworks. It's principles and it also involves teams working collaboratively and communicating openly within their team. So I hope that just gives you a bit of context on, on the definition that they give for, for agile software development. And we'll kind of go into that a bit more, fashion.
Project Experiences
So, my first experiences with agile were probably 2016 when I joined an it transformation thing.
within our organization and we would first thing to aggressively bring agile into the way we would develop new software. So our job at that time was the proof of concept. We came up with ideas for transformation, and then we had to turn it into a concept, prove the litter, that idea has value alone, and it was clear that waterfall wouldn't work for it because waterfall tends to be 12, 18 months.
It has a very definite outcome as you're driven by the outcome. Our first constraint was time. We had a three month window. So the idea was on day one and three months later, we had to have a proof of concept, but that was the first reason why we went for agile, because it's defined by the time you will deliver an output at the end of the given time, you know, and that we don't define exactly what the output is, but you will deliver company on that point.
So we decided to try agile. We didn't know agile, we didn't have experience of it. So, the first proof of concept we did with a company called BearingPoint, they brought a business platform to us and said, this will solve your world. And we'll build a proof of concept with you in 12 weeks to show it so that it can deliver it.
So they introduced a star general. That was the first thing that really set us up for success. We didn't try to do it on our own. We went with experts who knew how it should work. And who could lead us through the process. So the first, the first thing we have to get our head around was how do we establish a team for agile and waterfall?
We're very used to having, leads for different departments. They have a responsibility to communicate with the project, provide resources. and whatever I put you're looking for, but they tend to come and go, depending on where you are in your ward. Full-time when we set up our agile team, it becomes very clear.
We need to, not just people from each of the different functions we were working with, we need people who are committed to be available during the agile projects. So they had to be, yeah, there, when we needed them, there was none of this kind of, can you give me a set of definitions? And they come back and say, yeah, we'll do it in six weeks.
It was, can I have those definitions by the end of the night, you know, that person had to drop whatever else they were doing and be available to work on it. But we needed quite a heavy time commitment. Those people also had to be autonomous. They had to be able to make decisions very quickly from the nature of agile, we would, we were going to work using scrub.
So we were going to have two week sprints. That meant when we had a problem within the sprint pro sprint cycle, we needed an answer in hours, not weeks as waterfall, you tend to raise your questions at the project meeting, the project manager goes away, finds a solution, and then next month you have your answer and agile, we've got a problem.
We need it so that we need the answer to that. So we needed a commitment. We needed autonomy from those people. and that was, that was really tough to try and get these people to have both of those connect. When we have a chem lab, the next challenge was actually when we looked at the dynamic of the team.
It was much more integrated than when we used to work in there. So we had straight effective teams coming together. We had the business team, which had the requirements, it had the understanding of the outcome. It had the subject matter expertise in the field. We were doing our proof of concept. So we needed the right people from the business to come into our project.
We had the developers on the other side, who would turn this basic solution into what we needed it to be for the proof of concept. So that was, you know, business and developers. We need them in the same room together. The third thing we needed was really asked as the transformation team to bring both of those worlds together and help translate and get them working together, you know?
We had a product on Anna who was actually a product manager and the difference it's quite strange. We didn't appreciate that because the business product manager turns up and he's very used to, this is my product. You guys got to make it happen off to you in six months time. So he had to say, guys, you own the product.
manage the product. I mean, we're available every day. Every requirement that needs to be done, you own, you have to take responsibility for it. You have to make the decisions we have. We have the challenge. That's educate that. we had a scrum master who came from our out. Who's really good at helping to set up.
Brown ceremonies so that we could do out two weeks drunk sprints. And that led us into our second challenge. The first challenge product owner, make him a product donor second challenge, the sprint it's only two weeks, what we found. And it was really hard for us to get our head around until we put it on a whiteboard.
What's another two weeks sprint hikes, four weeks. And when you explain that to someone, they got no, hang up. No, it's just in the night, two weeks. It's going to be two weeks ago. No, it's all right. If you have the week before the sprint, when you're planning you going through your backlog, you're prioritizing and making sure each user's story has the right level of detail, context and understanding.
Then you've got your two week sprint and then the business hasn't spent the fourth week. I mean, it's user acceptance testing and signing off the output, the district so that, you know, that two week blocks in the middle was successful, you know, and I don't think we would've understood that if we hadn't have had actual coaches and expertise with us, you know, whenever we go into the bigger organization and say, we're going to take you down an agile journey.
We have to make that point. You can't necessarily do this successfully on your own because agile, isn't a process. It's a set of guidelines and you have to understand not just what the guidelines say, but the intention behind them and the purpose that they have to be able to implement them for your organization.
So that very first project we've learned a lot of valuable things and he convinced me that agile is the right way to do things. And I, the third learning I would put out there before I hand over to Renee is that you have to get used to the idea that you are defined by time, not requirement like two weeks, sprints is two weeks.
It cannot be two weeks. And one day it cannot be two weeks and three days, if your project is going to finish in 120 days, if finishes in 120 days, The variable is what you deliver in that time. And that's defined by your prioritization and your capability, you know, and I would say that the third impact on your output is your, is your scrum master because they control what happens to you in the scrum.
And the last thing you want is another senior manager comes trotting to the development team and goes, I know you're working on this, but can you just slide in this extra requirement and just do it? Which of course you can't allow it in a sprint, a sprint content or objective has been defined. You know, if anybody wants to put new stuff in, it has to go into the backlog.
You know, so big upset senior stakeholders when they can't do their, their little trick of throwing requirements in last minute and expecting you to move over and, and make them work. Everything goes into the backlog. The backlog is prioritized by the product owner and you agree on what you develop in each sprint Mo variation.
So that's kind of my very quick learnings from ad and why I liked it. Brilliant.
When I joined as a BA in 2011, so it was completely into waterfall metrics. So I wasn't too same waterfall. And like you had different teams and you have a project managers and your managers whom you're going and reporting and you're taking their requirements.
And then, when then, in 2017, that's when I moved to the agile process. So there was kind of a hybrid between. Waterfall and agile, because it was not an initial or shift altogether, and this was a banking project and it was totally a different exposure of like you have only yourself in, you're not having any documentation, kind of a thing that you are going to prepare in an agile.
so you had to. the create a user stories and you have a G a platform. so that was a small bit of a project, which I was handling, but, and then later I moved to a complete total moot move to agile process. And that was a quite big challenge at the initial phase, because coming from a waterfall background, you're totally, New to this agile methodology you need to do, do a lot of homework before getting into it.
And the kind of good exposure was here. It's like, I get to write, the user stories, create the epics to Epic. pick one, then break down those, requirements. And you had a sprint for like, as Pete already mentioned for, whereas it was two weeks further. And when for us, it was like, or more or less, or the same timelines.
And we had, how for each sprint every day we had, meetings and, daily stand up meetings. And then, so it was all a total learning for me when I had to, when I had a moody to. That was, again, it was not into banking project. It was an aviation project. And that was a total shift again. So you need to, as a B a, you need to adapt it.
And if you're like new to that particular field, you need to learn quite quickly and get it to put your shoes and just to the project and learn about it. But the best part was in agile. It itself. It has a short term goals that you can, it's not like you have put too much onto your plate. It's not like that.
You have like, the prioritization of the requirements is being made. You have a backlog, you have products being defined and each user stories, you have a set of prioritization being made and you have a timeframe where you can easily accept new changes coming in. So that was the exposure, which I got it.
It was quite good, things going on.
On some of my projects, a lot of the people where were previously working are using the waterfall methodology, including me. So when I stepped into this retailer, and we try to use agile ways of working, you know, it's a struggle at first, it's almost like a mindset shift. You know, going from traditional wards, full projects into the agile environment.
And there's so many new things to learn. For example, JIRA or Azure DevOps or whatever tool you might use for backlog management. So it's not just the toolings you have to get used to. It's the team environment. It's the stand ups, it's the scrum meetings. That's the prioritization of the backlog. You know, a lot of those concepts are new and were new to me as well.
So, a bit like Pete was saying as well with those sprints, you don't just come in and go, well, the sprint is two weeks. So where's my product at the end of two weeks. It's a lot more than that. You know, there's a lot of research that goes in, in the end near shore instance, you know, to. To kind of get that backlog up and running and get also the user stories within that backlog.
Actually there, from my perspective, from a BA I would say that actually getting those user stories ready for each sprint is often a challenge. You're always playing catch up because the, you know, the sprints are on new really fast and you deliver one sprint and then you're expensive. To deliver more stories in the backlog.
So I found myself, you know, it's a bit of a struggle to actually get those user stories ready for each sprint. So sometimes we have to actually pause the sprints to allow time for the BA to actually get those stories into the backlog, to articulate them, to get them signed off with the business. First, all your things like the prototypes.
Ready? Yeah. We have to make sure, you know, we attached to the prototypes, make sure they're signed off first and actually ready for delivery. So that doesn't take 10 minutes. You know, that takes some time to actually do that, to get your requirements ready for the backlog. So there are a couple of the issues that we had.
also in terms of teams, we have cross-functional teams and we also had teams that were, you know, geographically dispersed, if you like. So there were some people in India, some in America, you know, some in, In Europe, and obviously some in England. So keeping that communication as well in agile, is difficult when you're working with teams that are, in different locations as well.
So we have things to help us like, you know, Skype or we would phone them or we'd use teams or something like that to communicate. So that was quite difficult as well. You know, it's a lot easier when everyone's based on the same site, you know, you can physically communicate with them. So that's another challenge that we had, also as well.
Yeah, it's kind of an education piece. As Pete said before, if people aren't trained properly in using these tools or training, communicating, or you don't have maybe a good scrum master or something to manage those meetings and keep them on track and keep them to time, it, it can get quite tricky, to, to coordinate those things.
So, I think in terms of the project itself, we're actually delivering a mobile application. so we had a UX team, that was involved with us to do, to do all the prototypes and things. so we had to communicate a lot with them, as well within the team and involve them. so what we did is we basically, we discussed these new ways of working, decided how we're going to do things, what tool and we were going to use.
And we've run a few sprints as basically a trial, just to get used to things with the new backlog. and once basically momentum had started, the backlog had started to expand. we basically, we prioritized all of those user stories. And what we found is that every sprint you kind of get better at doing things.
You get more efficient, you know, things that took time before and now a lot quicker because you've done your, you know, your sprint zero you've, perhaps, you know, and as the sprints go on, you learn more and more. So, it, to me just, and really it's all about mindset, especially within our Joe is having the mindset to deliver in an agile fashion.
So it's changing your traditional approaches, you know, from waterfall, as I said previously, over to agile. So that was me really. That was just a bit about my project. I think it might be worth us talking a bit more about user stories, because that was certainly. One of the hardest concepts we had to get across to people who were joining the project.
So what we found with user stories was everybody's seeing the slide that says a user story is I am a customer. I want to do a task. So I get a benefit. Right. And everybody's like, that's great. I can write that. So what we found initially was we had a product owner who wrote. 1220 user stories. So we'd literally just one sentence and we had to go, it's actually not that that's your title for the user story that sets the context, but behind that, there were so many other things that we need to know to really make that user story useful to a developer who doesn't know your environment.
Doesn't know your product, doesn't know your customer and actually doesn't know what you want. You know, he knows who's going to do what and why, but he needs to know what you, as the product owners see as the outcome from that. So you say you need things like a mock-up screen. Mock-up wireframes he needs to put that user story in the context of the other user stories.
So, you know, which user stories come before it, which uses stories come after it, you know? And, you need to. Dependencies which tools are going to be involved, which processes, which data sources, you know, there's a lot of things we found that you need to document for a developer type of understanding what is meant by that user story.
So that was the first thing I think is important. Like if you're a BA and you're writing user stories, you are going to have to go into more detail in an agile project quickly than you will in a waterfall project. Yes. I agree. You're going to have to pull that out of your product owner or your business.
team members and it is literally like pulling teeth because they're not used to this. They're not used to thinking about the how, of what they want. They want, they want to find out when a mobile app, someone can log in, someone can look at a catalog, someone can purchase, you're asking them, what does that actually look like?
What, what, what is the login experience you see for your customer? How do you want your product to present itself to the customer and interact with them? I've found a lot of product managers just. Look at you blindly. And it's kind of like that sort of caught in your headlights, so don't know what you want, but you're forcing products, people to think about the product experience and the product method more than they're comfortable with, if they've not worked in HR.
So, you know, user stories are. Incredibly powerful, but really hard to get. Right. But once you start getting them right, you really see the value of them. The final point I would say is more, is better. It might sound a bit counter intuitive, but more user stories are better than. Let's I'll give an example.
We, we were doing a e-commerce platform in our first proof of concept and the product owner says we need a discounting structure and he wrote three user stories. I w as pricing manager, I want to give discount a, so the customer receives a lower price as pricing manager. I want to give discount B because the customer is a partner and we give them a special rate.
and as pricing manager discounts see, and so we thought, great, three years of stories. What were you guys those to the developers, they rejected them. I said, we can't do that. There's too many unknowns in that action. so, okay. So we, we sat down with them and we broke it down. And in the end we ended up with 16 user stories for three discounts because there's.
I want to create a discount. I want to define the rules of how that discount is applied. I want the discounts we presented this way on the screen. I want the discounts. We show this way in the final quotes. I want the discounts to be captured in the backend systems in this database. You know, so when we broke it down, actually, You know, more user stories gave us a greater level of granularity, which made it far easier for the developers to implement them.
And actually those, those 16 user stories they could do in a sprint. Whereas the three very big, very broad user stories, they said they couldn't complete in two Springs. And it's just that unknown. If you don't tell people exactly what you want in a meaningful way. You will not get the output you want, you know, and it doesn't matter how good your developers are.
The business has to own the user stories and it has to commit to spending the time and effort on them. You know, otherwise you as a BA is going to be lost because you won't be getting the inputs. You won't be getting the vision. You won't be getting all of the good stuff that makes it meaningful. For your developers.
Yeah, really interesting point actually, that happened on a lot of my projects. we found that the backlog was far too high level, so you get these very generic user stories that were, that were huge, you know, and when we went into those estimation sessions, they, they said, well, that's, you know, that's like a 32, Fibonacci, we use the Fibonacci sequence.
Sorry, but it was, yeah. It was a massive, massive story. and we got told to break that down, and it's kind of, yeah. Yeah, it's, it's tricky within a team to kind of get that level of detail, as you say, from those product owners as well. They kind of know what they want, but they don't know at that granular level what they want.
and it takes time to break that down. And we have also, we have, we found, we had so many acceptance criteria for a single story as well to say with something like, I want to add a product to their car. We found that there are like 50 acceptance criteria, you know, that I can add multiple items to the cart.
I can remove one, I can update one. I can, you know, we found that we had to break those down. and that, as you say, that requires a lot of input from that product owner to be there alongside you to do that. You know, whereas in waterfall, it's almost, you ask a question and then as you say, a few months later, you might get the answer.
I had similar experiences, as well. then about you arena, did you find that as well with your backlog? it was kind of getting product managers involved, breaking those stories down. Was it was the challenge. Yes. It was actually because I was in a project with a way to create a BI visualization report.
so that was, we had a third party application, which was, being implemented. And in this, we had the user stories and. And this was just seems to be a small product, which was more on a reporting and it was on visualization reporting. And, the, when we had taken these requirements, so we had to create the user stories.
And when they created the user stories we had to, before that. We can take the epics and then we decomposed, the user requirements. So that was quite challenging because for each reporting you have multiple scenarios and most of them, they were make many changes into that. And you need to have a, product expertise in that where that person can clearly give via an SME that, so that was a quite challenging on relating your as a VA rating your user stories with the product and that, That was quite a very tough time in the initial phase.
so once the couple of reporting have been cleared and. Successfully processed. So then we had the other multiple reporting comes in. That was one big thing. And when you have a set of user stories, you have a prioritization being made for each of the use they're required, then you upload them into the JIRA.
So I was using DevOps Hazara. application where we had all the requirements been already been updated and your test cases, and you have all the reports in generated that. So that was quite a good thing, but the, initially it was quite a challenge actually. Yeah, I think, I think we're actually having another session on that actually, CP you've just put yourself forward for the next session chairs.
That'd be great. It'd be great to actually have an additional session we can share or something in. We can run through user stories and some of the experiences, you know, with that. Cause I know there's a lot of, I know I found it a struggle to actually get the granularity of user stories and defining it at a certain level.
You know, there's quite an art to actually forming those users. The, what, what we did initially, we, we, from our first few projects, we created a framework that we thought would work for most parts of our company. we shared it with different teams in it, in product development for they're there to get their feedback.
the, it adopted the same framework, the product, what teams, where we have the challenge. Cause they, they liked the concept of agile, but they. They felt agile was too light for product releases. You know, they had a very heavy waterfall product process where a new release was every 12 months and they were very comfortable with that and they couldn't get their head around this idea of a roadmap in agile.
So they adopted a version of agile called scaled agile. Which I can highly highly recommend no one follows ever, because it's basically, it was created by a well-known consultancy firm that I won't mention it. They used to get upset, as a way of kind of bringing the high-level structure of waterfall into an agile environment.
So you will have release trains, which are your roadmap within release trains. You have your release cycles and then within release cycles, you have your agile. Things. And what we found was it just created a lot of confusion because there was too much overlap. There's too much. We'll take this bits of waterfall and this bits of agile we'll mesh them together.
It didn't work. So what, what really works best, I think is when you let you follow the principles of the agile manifesto and you let the teams be self-organizing. And figure out what works for that particular project team. There are some basic principles you have to have in place. You have to have the roles, you have to have the backlog.
You have to decide which version of agile you're using for development. Are you using scrim or scrum, sorry, or Kanban or lean, you know, but if the teams are allowed to organize it and find the working rhythm and pattern that fits them as a project team or an agile team, they will deliver an outcome. And they will be proud of that outcome and you will be happy with the results it's when you try and get too prescriptive without gel that I see it falling down.
And that's why I think scaled agile doesn't work. You know, the experiences we saw were pretty horrible. You know, you have to allow for the self autonomy because that really drives the development things. They can organize their work, they can make decisions. They can really focus on how to achieve your, this current development cycle.
And what they can achieve in it, you know, rather than having it take it to them and forced on them, there's nothing worse for a development team than being given 40 weeks of work to do in 20 weeks, which is what happens at the end of every waterfall project. When you realize that your deadline is, is going to have to be pushed out.
So you put pressure on the teams to do more. It really is the motivating. So I would say. There's nothing wrong with different versions of agile, as long as needs change. It's self-organizing they have the right level of autonomy. And at the end you're getting good quality outputs from them. It's fine. But half basic principles that everyone has to adhere to like the roles, the mythology, the backlog management.
and I have clear expectations from the senior stakeholders down as well. So they've got a chance to meet them. Yeah, it's already mentioned, when my previous project, it was a, more of a combination of waterfall and agile, even a joint into a deal form in the banking sector. And that, that was like, we, it was.
So not much of a change because like people were trying to, we're a bit confused because, which method to follow and how this, total approach is going through because the management has a different way of explaining. And when you have, from a waterfall background, you tend to try to connect the dots between.
All these, and that's when the approach was there. But when moved to a complete agile project, you have a clear understanding of what you are going through. And here we use more of a Kanban, framework. Like we had visualizations of the requirement being prioritized on the board when, and these were discussed in our daily standup meetings.
So that is one of the approach, which I had personally gone through this story point, estimations. Are always bad in the first sprint and spot on in the last sprint and then everything in between. You could the challenge when you put a new team together for a new sprint, a new project, and you go into your first sprint, your all work learning to work together.
So you are going to overestimate the work you can do. And that should be expected. You know, a good scrum master, a good product owner know this, they know in week, the first spring you're going overestimate. You're not going to get all of the deliverables. It's a learning exercise. And it's part of the agile process.
Your development team have to establish a rhythm of working, which establishes their velocity. And the only way you get better at understanding it is going by sprint by sprint. During the story point estimation, you can limit how wrong you are. Having said that by limiting, putting some rules around your story by estimation.
So we start off by using a one, two, three, five, nine, 15 at that story points. So everything has fed into one of those. And what we realized was that anything that was a 15, a nine or a five was way too complex and had a huge impact on our velocity. And really reduce the amount of work we could do because of the complexity.
So what we S we started saying, we brought it forward into our future projects was everything's going to be a one, two or three. If a, the developers look at a user story and say, that's a five, we will say, okay, can we turn it into a three or two before the sprint starts? If not, it's. Which not in the sprint.
If it's a nine, it's not in the spring, if it's a 15, you haven't done your job. So go away and rework that completely. So yeah. Story estimations will go wrong in the first few sprints because you're learning, but you can limit, you can, then you could kind of limit the impact. By setting some boundaries on what you will accept as a user story in terms of story points.
And that will also help maintain your velocity and potentially improve it over time. Thanks, Pete. And how just out of interest, how did you reduce that estimation? Was it a case of splitting that story down further? Exactly. Yes. A story point estimation is actually a reflection of the, either the complexity or the ambiguity in a story.
So if it's too complex, it's going to take too long. If it, if it's not clear enough, it's it can't be developed easily. So when somebody says, you know, this, this story is a five, you know, it's a little bit too complex or it's a little bit so unclear, go away quickly, rework it, figure it out, represent it in my drop two or three or.
You know, if it stays at five, you've addressed the wrong thing, go back. Anything that was a nine or a 15, you know, our developers were really good that just when it was going to take them too long to do it in one sprint, it was too complex or it was so badly written. They were going to spend half the spreads, scratching their heads, trying to figure out what the hell are we doing here?
You know? So yeah, it takes a little practice, but. for me, it's one of the beauties of this principle of self organizing and so forth. Some are week. If you work as per the scrum process, after the agile process, you start learning how to work together better. And over time you become much more efficient.
You become much more effective, you know, and it actually becomes quite fun working together. So what are the pitfalls of working in agile teams and how do we overcome these issues? so we've, we've covered, some of those pitfalls, but I think in terms of, for our audience, just some best tips on how to overcome some, some of those issues.
And actually when working in agile, yeah. The first one is learning to manage upwards. There are a lot of senior stakeholders who assume agile means they can change their mind on Monday and you will have it sorted by Tuesday, but you. For it to be effective. Your senior leaders need to understand that agile.
It doesn't mean that you can change your mind every day. Agile means you will get consistent deliveries of value. Every sprint. It might not be exactly what you want. It might not be to the depths of scope that you want, but every sprint or every cycle, if you're using CAMBA will deliver value. For your products.
And at some point you will have a minimum viable product you can release to your customers, but they cannot come in and say, we've changed our minds. You need to focus on feature a rather than feature B, that they have to go through a change control process with your HR team. It has to be go into the backlog.
It has to be prioritized those fights or whatever. It's fine to change direction. But it has to be done properly within the framework of our job or your, or your development team. We're going to get disheartened. You're going to throw away a lot of development. You're not going to achieve a meaningful outcome.
And so that would be my first pitfall. The second one is I think you need to have a bit of patience with the, with your team in the first few sprints to get the hang of how they work together. And you have to allow them to work together. You know, you have to allow them to figure out story points, what works for them.
You have to allow them to get comfortable raising concerns about user stories. You have to allow the time to get used to the ceremonies that go with sprint. If you're using sprint. If you rush people into doing a prescriptive agile framework, that they haven't had time to get their head round, you don't give them the space to breathe within it and make it work for themselves.
Again, it will fail, you know, so those are the two things I would go, you know, learn to manage upwards, give your agile teams space to get their version of agile working. One very important factor is the communication, the first thing, and you need to know the right stakeholders in an agile project. And, so, the pitfalls is generally what happens.
They, a few things are there when your requirements are like frequent changes in your requirements. That is one of the challenges, which you generally face it. And then you go to the developer and the developer is like, he keeps changing it. And as Pete already mentioned, you need to have a lot of patients when you have to come through all these things.
Okay. So, communication as well, one of the important factors, sometimes what happens in an agile project, you have a sign of being done. And then again, you have a. Oh, it changes being there. Again, you have to come back the developer and get that testing done. So that is one of the key factor, which I would see that, you need to understand your stakeholders and the project very well before, getting into all these things.
So it was, how do we educate existing teams? Speed, better agile ways of working and any tips on driving the agile agenda within teams were used to what they think is agile. But in fact, using YGL method, both waterfall and agile DACA, I'll try and keep this brief. so I would say set boundaries. What does agile mean for your company?
What do we mean by agile? What do we expect from it? second communicate, best practice, whether it's from your company or from other companies. And third invest some time in educating people. It works really well. Run a one day workshop internally. You don't need to get to someone's head and get people talking about agile sharing, how they work, sharing what works for them.
Give them the opportunity to learn from each other.
Brilliant. Thanks so much, Pete. Thank you. And Aroona just to finish.
Yeah, I would agree with Pete what, the, what he has communicated with, regarding how to think that there's more of what you need to work towards any assignment, which you have been part of it, and you have lots of people who will be around with them. Who can help you out. And, again, it is how you communicate well with everything.
Conclusion
Thanks for your time. There's loads of very useful experiences in there. And I know I've learned a lot as well, just from hearing you speak. so thanks very much for your time and thanks also to the audience, for joining us today. And we'll we'll end there.
This article is a transcript of the BA Video Series Linkedin Live video on Best Practises in the Agile World
You can also listen to this via our podcast
If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com