If you are a beginner project manager in software development that has heard of Agile but doesn't really know when or when not to use this methodology, then this blog is for you. Before you get started reading, this post is assuming that you already know a little bit about Agile and what it is used for in software development. There is a lot of buzz and information out there about Agile software development but a lot of people don't really know the time and place to use it. As helpful as this methodology is, it is not meant to be used for certain projects and that is what will be discussed later on. First we will talk about when to use Agile and then go into some examples and illustrations.
We will start off this section by mentioning that Agile is a very useful methodology not only for software development (even though that is where it is commonly found) but also for other fields of work that include big projects. In the next paragraph I will list some of the ways in which you will know if Agile is for you and your team.
One of the reasons to use Agile would be if the stakeholders for the project would like to have a quick delivery of the product. That is, while the project is being worked on, the product should be able to be viewed and used in a “complete” state. Complete being in quotation marks because it is fully complete but complete enough to be used and critiqued after each sprint. This is very useful in the business world because there is constant competition and pressure to get products out quickly. That leads us into another reason why Agile might be a good methodology for you to use.
Agile is very useful to use when the scope of the project is pretty wide and is open to being changed. This can happen in the business world as well when there are customers to be satisfied by your product. Just think about how your own personal mood and feelings about something might change in a day, a week, or even a month. Now take into consideration about a large group of people and how hard it might be to satisfy that group on the first release of a product. Now you are beginning to see how useful Agile might be for a lot of projects. It allows for a good deal of change to a product within its structure and in the methodology itself.
An example for a project that would benefit from Agile would look something like this. Imagine that a company has hired you and your team to make an iPhone app as their product that they are selling to their customers. They would like to be able to see the progress as it is being made and want to be able to get a product out to their customers as soon as possible as they have promised them the app would be delivered soon. The product owners at this company warned you up front that their customers are pretty demanding and tend to change their mind on what they like and don’t like. This means that you and your team will have to be pretty flexible when it comes to meeting the demands of the customers after the first release of the project. I don't know how you feel but this seems like the perfect recipe for Agile!
Now with all of the positives of Agile out of the way, let’s discuss some of the times when Agile would not be a useful methodology/tool to use. The first we will discuss is when the project in mention has a fixed scope and is not really open to change nearly as much as other projects. In this scenario you could still use Agile but it would probably not be in your best interest as a project manager to use it in this context. Another reason not to use Agile is if your project has a fixed price point, meaning that there is very little to none wiggle room on the financing of the project and it needs to be completed on a certain budget. This is important because due to the changing nature of Agile, there is a possibility that the budget of the project may have to increase to meet the demands of the product owner or stakeholders.
Another way to determine if you can even do Agile or not is if there is a lot of documentation needed for the project because the more documentation and descriptions that you need to do will decrease the likelihood that Agile will work for that project. Kind of tying into that aspect is how rigid the restrictions of the project are. If the project has pretty tight restrictions on what needs to be done and when, then Agile is not going to be the best approach for you and your team.
Take for example, a project that has been assigned to you and your team. You are a part of a software development company that handles a lot of financial based products. A restaurant has hired you to develop software that automates their finances so that they can focus on the food and logistics of actually running a restaurant without worrying about things like on time payments. Now this company has a pretty tight budget and timeline for this project and there will not be much wiggle room for you and your team. You also realize that this project has a pretty well-defined scope and is not likely to change any, if at all. This seems like the type of project that would not benefit very much from the Agile approach.
I hope you have gained some valuable insight into when you should choose Agile as your methodology for a project. The examples that were laid out should be helpful in understanding from a practical standpoint what types of projects would benefit from Agile. Make sure to check out the other blogs on our site. Have a Great Day!
Sources:
Wiszowaty, Karol. “When to Use Agile Project Management and When Not To?” Polish Software House: Inspeerity, 6 July 2022, inspeerity.com/blog/how-to-know-if-agile-is-good-for-your-project.
Comments