Agility is such a great skill to have. It can really help you with the hustle and bustle of your daily life by keeping your mind and body sharp and prone to quick decision-making. Well, this skill is even more sought after in the business and tech industry. Not just for that sharpness we mentioned, but also because agile people tend to be more innovative and adaptable. With all the rapid and constant changes being introduced into organizations on a daily basis, this skill is increasingly shifting away from the “nice-to-have” category to the “must-have” one. With that in mind, we need to consider that our processes and methodologies also need to be more agile. Let’s show you exactly what we mean, though!
Waterfalls and Agile Rivers
With so many different projects out there, we can’t really say for certain that one project management methodology will be good enough to cover them. Throughout the years plenty of varied techniques have popped up, all in the interest to give you the guidelines to adequately deal with the job at hand. Some of the more popular ones you might see are the waterfall, agile, and its several sub-framework methodologies.
Naturally, they were developed to deal with specific requirements. For example, you’d use the waterfall one if your process flows in one direction and you don’t go back and change things ad hoc, while you’d use the agile one if you aren’t sure what the end product should look like and want to piece it out gradually. In short, if you know you want a rocket, then go with the waterfall, but if you know that you want something that flies, then you may want to go with agile.
Let’s make one thing clear here! When we previously said that our processes and methodologies need to be more agile, we weren’t talking specifically about the agile method and its sub-frameworks. Instead, we meant that, as a whole, we need to be informed and adaptable with the techniques we choose. You know what, this might be a good time to show you what we mean with an example or two.
Examples, Lead the Way!
As always, we’ll present you with hypotheticals driven by our own past experiences. And the first case we’ll look at is the “I have all this data, but I don’t really know how to utilize it” situation. Naturally, after talking with the client and analyzing the data, you create a list of user stories and then tasks which will gradually build a usable product for the client. Since they’re unsure, though, you decide to go with the agile methodology and present them with a workable version every few weeks, so they can choose which direction the product should head in.
Okay, that was a clear and easy example. Let’s check out the “I need to collect all my data in one place and monitor it from there” situation. Here you encounter a client with a whole list of things that need to be done. So, they already kind of know what they want, but you’ll have to deal with the prioritization of the tasks yourself. In this case, since the client has an idea of what they’re expecting to see as an end-product but doesn’t know what exactly it would look like, we can clearly move on with the agile methodology again. However, because they’ve already provided you with a list of tasks, or in other words – a backlog, you should utilize one of the agile sub-frameworks – Kanban. This way, the business will have a clear idea of the progress of each assignment.
I know we said two examples, but let’s give you one more for good measure. So, this last one will be the “I know what I want, but don’t have the time or resources to make it” situation. It’s probably one of the most common project types, where the client gives you all you need and explains what they require as a final product. This clear-cut case can be approached with the waterfall methodology, especially if the client will have no feedback throughout the various steps of the process.
Conclusion
When you look at these examples as standalone cases, they probably won’t impress you much. However, observing them through the viewpoint of an agile and adaptable company changes things quite a bit. Recognizing when and why you need to switch up your approaches based on the project at hand is the key takeaway we’re trying to get at here. So, think on that for a bit because an agile mindset knows no bounds.
