Contact Fatema:
LinkedIn - https://www.linkedin.com/in/fatemaelwakeelmbacma/

Fatema's Blog: https://strategicalanalytics.com/

Fatema's Articles:

FULL EPISODE TRANSCRIPT

Adam: (00:00)

Welcome back to Count Me In, IMA's podcast about all things affecting the accounting and finance world. I'm your host, Adam Larson. And this week's episode, Mitch was joined by Fatema El-Zahraa El-Wakeel to talk about agile project management methodology. Fatema helps us understand agile by breaking down the process and giving us a simple how to, when looking to start using this project management methodology. Let's listen to learn more. 

 

Fatema: (00:30)

So traditional project management model is really what we're used to seeing for several years. It consists of a project manager and a team of specialists who work on a project. The project team begins by meeting with the customer, can be another department or another company and external party depending on the project. And then once they collect the project requirements, they break it down into milestones. And then the project manager is tasked with keeping the customer posted on the status and completing the project. This model is really vulnerable to a lot of things like delays, miscalculations or unforeseen costs, which can be caused by the budget overruns or an overall failure to deliver a stated goals. 

 

Mitch: (01:25)

How is the agile project management different than the waterfall method in terms of, you know, the variables that come along with the project and which methodology is better for analytics. 

 

Fatema: (01:39)

So when you look at any project, really there are three main variables. The time set for the project, the resources that the project will be using, and the main thing is the scope. Oh, and in a traditional project management, the scope is fixed and obviously you can increase the resources by increasing the budget signing off an additional budget or adding additional employees to the project, the time needed is an estimate. People like to fix it. But normally, unfortunately you see overrun. In agile project management, the resources and time components are more fixed. While the scope is estimated. So you know that kind of the direction where you're going but it is not set on set in stone somehow. In agile because, because we are really responding to like the business needs. So we re we prefer using it in analytics project rather than sticking to a scope that is fixed. So normally what happens is a product owner, the product owner and the customer would agree on a, an MVP, which is the minimum viable product. I'm using this method. The time spent for the MVPs for each iteration is called a sprint. And at the beginning of the sprint normally the customer and the project team, agree on the sprint goals and the MVPs that are expected. And then they kind of establish a plan really to complete the work. And at the end of the sprint, the project team goes back to the customer to show the MVP and get the feedback. So they show the customer a demo of what they've done so far. Sometimes even you can go live with part of the project and launch it. And I think this is the benefit of using agile methodology in data analytics because you're utilizing the data. 

 

Mitch: (03:41)

Now I know there are a lot of terms that I'm sure our listeners hear frequently, but may not necessarily know what they mean. So within the agile project management methodology, what are some of the most important facets and some of the terms that you should really understand to understand agile project management? 

 

Fatema: (04:01)

That's a great question, Mitch really, because I think when you start using agile project management it's a bit overwhelming. Like when I first started i was like what are all those terminologies that people use? And what does that mean? I think few of them, well one of it is, for example the scrum and I'm a scrum is or no, those are normally regular meetings to reviews the progress of the adult project, similar to a project management manager. Oh the scrum master oversees the development process and ensures everyone is on track and it's really aligned to the planned sprints. Another term used is scrum of scrums and that happens when you have several projects, multiple teams working on different projects and they need to keep the wider team updated. Product backlog is another, term that is widely used and you can see as like list of tasks to be completed by the team, open items that the team needs to go through and kind of close in each sprint. Normally the product, owner and manages the backlog to ensure the product delivery. So he or she discusses with the, which items on the backlog need to be done. There's different like labeling, like if it's a should or could. How important is the item on the backlog. 

 

Mitch: (05:35)

Now that we have a better understanding of the terminology that goes into agile project management, what is a practical example? Can you give us a case study or something that you've worked on where all of this kind of comes together?

 

Fatema: (05:50)

So let me think of an example. So, let's say a customer described some challenges with current reporting used for pricing and they explained that they would like, that's a visualization to understand relevant issues. So it's basically a visualization and analytics project. So I'm the agreed MVP in this case or the minimum viable project would be a dashboard that helps report pricing. The team working on the project agrees with the customer to me by weekly for example, and review the progress and MVPs based on expected sprint deliverables at the start. As you can see from here, the project time is agreed and it might be three months and the number of team members is, for example, set to five. So the main, the three main, um, facets, it's really of the radar project management is you have a scope, you know, the direction where you are, and in this case you're going towards a visualization project. You have the time set, which is three months, and you have the resources set, which in this case the team members, the five team members, Oh, the product owner in this case create some backlog listing the tasks needed such as tools used for the visualization, preliminary KPIs and other reporting requirements. The scrum meetings normally would occur daily and the scrum master would ensure everything is on track. A scrum meeting is normally like 10 minutes and it's a stand up. So everyone in the team would just say what they've done this day before what they're doing today. And like if there are any blockers so that in this case the scrum master would unblock those challenges that the team is facing. If you assume that at the end of sprint one the team meets with the customer to present and discuss the print preliminary KPI and the basic dashboards. So it's still the start of the project and the customer provides some feedback. The team takes that feedback, goes back, works a bit on it, refines the products and goes back to the customer. If you assume that in the second time they go to the customer, the customer would say, well, Oh, I actually was expecting more details on pricing optimization. The team in this case would think would go back, check it, come back. But when they come back they might say, well, we were supposed to go into a direction of doing a visualization. You're asking us now to do a pricing optimization case, which is good. But that's a different scope now. So they sit with the customer and then they agree what is really important based on the current business needs. So the team might agree with the customer that the model is priority and the customer might explain that. And in this case team works on sprint three, but delivers the variables that affecting the pricing as well as explained the different internal and external sources. You can see here that there is a happier customer although the product was different, well the customer received better functionality. So instead of the team, if it was run by a traditional project management, the customer would get at the end list of KPIs visualized in a certain way and the customer might not even have seen that product at the very end. But with Agile, what happened here is that the team was very responsive to the business needs. 

 

Mitch: (09:42)

I think that's a really good example and it really covers the difference between the two methodologies. So how important is it to have a strong team in agile? 

 

Fatema: (09:54)

Oh agile focuses on the project team. So the project success really is attributable to the whole team and it creates this kind of culture and strength in the project. So the project is it's a whole team collaboration and responsibility. It's very team centric. There is no project manager in agile. This role is somehow split by the product owner and the scrum master with neither leading the team, but rather focusing on the product itself and working with the team. So the product owner focuses on ensuring customer needs are met, scrum master is part of the team, having the responsibility to facilitate the team and not really to lead them just to support them by unblocking any any blockers that might arise during the project. 

 

Mitch: (10:48)

If any of the listeners are kind of like me, where we've worked on projects and we kind of see the resemblance here of what we're doing in the agile method, how can we better learn more about agile and how to actually use it? 

 

Fatema: (11:04)

I think that's a brilliant question, Mitch. Because I think personally when I started using agile, I was so confused. I'll be very honest, coming from a traditional project management, and moving to agile. It's all about the mindset somehow. And it takes time to change your mindset from the traditional waterfall method. So the best way to learn it or how I learned it to be honest, is really by doing so start using it and work your way through it. Find an Agile coach or someone who uses agile to bounce ideas off, ask them questions. This will help you learn a lot. And put kind of the theory into practice somehow. 

 

Mitch: (11:50)

I know earlier you mentioned one of the opportunities being stronger data analytics. So how do you go about presenting agile and data analytics to your team as a project management method to use moving forward? 

 

Fatema: (12:04)

The first thing would be if it's possible, look into ways to deliver the results as soon as possible. Like have quick wins really. Start by rolling out a test phase. So stakeholders can begin to see the benefits of the project and the methodology early on. Stakeholders will also understand that they're part of how the project is shaped and they get to see the different iterations and changes. This will encourage the buy in into agile especially if you haven't seen or haven't used the methodology before. 

 

Mitch: (12:41)

How about the other side of this? What are some of the challenges with agile? 

 

Fatema: (12:46)

So well there are a few challenges. The first challenge is getting used to the fact that as I mentioned before like the project scope is really open. In Waterfall, you usually know what the end result will be and it's not really the case with agile. You know, your direction, you might have an idea of what the end goal would be. Might be clear sometimes, but it might be not, we know roughly what the end product would be. It can change dramatically due to the business needs. So I think one of the challenges is for the person doing agile not to get fixated on the original scope. But think about delivering functioning product that the stakeholder needs or the customer needs based on operating in a fast paced world. It's not a target that you need to compare to traditional. It's not like a target end scope, but rather want to make sure that I'm delivering the functional product that my customer would use. The second challenge is that time is fixed and it set in at the start. So make sure that there isn't any time. Sometimes, especially maybe customers they call this, they get a bit confused and say, Oh, can we just extend the timeline and add this and that feature to the project? You can always add phases but try to stick to time so it needs to stay well this is phase one and those are the deliverables. This is the MVP. MVP delivered. It kind of structures the project better. I think the last thing would be really sprints and requirements breakdown. This would basically come with experience. So the first project would be more challenging than the second. So just really start and get the ball rolling. We all started somewhere with no experience. Just make sure to have the right team to support and be a great team member and you learn quickly. 

 

Mitch: (15:00)

So if I were to try and start an agile project, you know, going back to something you mentioned earlier the backlog being the, the list of tasks, what does that look like? How do I actually start the project and, and create a backlog. 

 

Fatema: (15:14)

If you think proper backlog as a list of tasks really. So each project has a backlog and it should be completed by the team. Having said that, sometimes some of the backlog items or some of the tasks are not done because it was agreed that you're not using them at all. So the backlog is written in the form of stories that describe the task. It can be key words or sentences as long as they are kind of understandable in terms of the level of detail needed for the team to understand. Stories are normally recorded in the backlog in a form. Normally what people use is as a user I want to, so that the reason. So for example if I'm an end use, I'll say, well, as an end user I want to be able to calculate customer profitability so that I can approve relevant discounts. 

 

Mitch: (16:14)

Now we know the backlog is kind of created around a story. What are some other important terms or are key things that we should be aware of in the agile project method methodology? 

 

Fatema: (16:27)

One of the terms that is used is releases which are basically kind of versions of the product. For example if someone is working on a pricing model across regions, the first release might be testing it to the top 10 customer data. And that's a release. The second release can be testing the data of old customers in the United States. And then a third release can be, well, having this worldwide and because agile is an iterative method, having different releases, but this can ensure a smoother final product run out. 

 

Mitch: (17:11)

So what is the end result? How do we close out the backlog or the initial task that we listed for this project? 

 

Fatema: (17:22)

This is a great question cause sometimes you have a task and is that task closed? Is that backlog item closed or is it open that is when it comes, the definition of done or the DOD. And this is when the team really agrees on a rule to consider a task from the backlog as done. So DOD differs from one project to another but is agreed upon by each scrum team. Like for example, DOD can be when a code is written or tested or when a release is complete. 

 

Announcer: (18:02)

This has been Count Me In, IMA's podcast providing you with the latest perspectives of thought leaders from the accounting and finance profession. If you like what you heard and you'd like to be counted in from more relevant accounting and finance education, visit IMA's website at www.imenet.org.