Agile methodology explained

Erika Hamilton
7 min readDec 11, 2020

Project management is an artform and relevant in all types of work — there’s always clients, budgets, and a product to measure in whatever industry you’re in. In the world of software development, it’s just the same, but we build an imaginary skyscraper. It takes just as much time and planning (and often budget) as constructing a physical building, so we’ve got to be ultra-organised to make it happen.

We’ve been a big fan of the Agile Methodology, and have begun to fully embrace all sides of this project management process within our organisation over the last 12 months — which has been made extra efficient with the assistance of the Atlassian suite of products.

What’s the right style for you?

We’ve played around with a few different project management styles and often swap between two of the biggest ones depending on the project. Just like how there are specific cooking utensils that are required to cook specific dishes, there are different project management styles that suit each type of project. The most important part of the project management style is to ensure it suits the needs of your team, your product, and your customer.

We’ve done a deep dive into Waterfall and Agile management styles so you don’t have to — these are some of the most popular project management styles within software development and two of the methods we use here at HutSix.

Waterfall is one of the oldest project management styles out there, beginning in the 1970s with the start of the complex nature of software development within the computing community. It’s become widely adopted throughout the community. It’s popularity comes from the fact that it is sequential. Waterfall is named as such because there is a definitive start and end of a waterfall — the water moves one continual direction, with outlined stops along the way. As does the project management method.

Each stage within this process is wrapped up before you move onto the next one — with the client testing and having access to it at the very end of the development. This can be a very helpful management tool if you have a detailed scope on exactly what the client is after. It can take more time at the start of the project finalising the scope and designing the solution, catering for any fixes well in advance.

This model is really easy to understand for a client and for your team, it’s much like baking a cake, you create the recipe, follow it to a tee, and produce a finished product that is (hopefully) just like the picture on the box. The stages of Waterfall development help keep everyone accountable and encourages strong documentation throughout (which is always a struggle for developers).

The biggest downside of this development style is that it is super high risk, if you haven’t accounted for something in your scoping process or need to change something, you’re going to have to start all over again. If the client changes their mind on what they want, you’ll have to start again. A big risk within the software development space in particular is that the output may change when you’re finally ready to launch. If a project takes a few years, some of the technology used may be out of date so you’ll need to go back and update everything before it can go live.

We use this method to develop all of our websites as they do need to be built in quite a linear function. It’s difficult to input content into or launch a website that hasn’t been designed yet! For some of our larger websites — and all of our apps — we use the Agile methodology.

Agile software development is newer than Waterfall, emerging officially in 2001 with the release of the book the ‘Agile Manifesto’. Agile is the complete opposite of Waterfall in its approach and ideology. In Agile development, there are no top-heavy scoping components at the start of a project — you work on the fly. The process is all about making iterations with small incremental changes that respond to the clients feedback and changes to technological requirements.

Agile is much like getting dressed in the morning, even though you’ve planned what you’ll wear — even if it’s just doing your washing or buying the clothes — but we accept that things might change, it might start raining or your plans change. Agile is about acknowledging that these changes are okay as long as what you end up deciding on is fit for purpose and you get out the door on time. Sure, you might make a mistake and go out without a coat when you probably should’ve taken one, but you can always run back and get one to fix the problem.

Agile is really reliant on client feedback and continual testing, compared to Waterfall which is reliant on the client using the system once everything is done, Agile involves sharing each phase with the client as it is built, which usually takes about 2–4 weeks. The client is able to give feedback on where the direction should go and how it should look at the next phase. This allows us to get feedback — and make mistakes — in a controlled environment (the stakes aren’t super high because the product is not yet live).

This method is super collaborative, so everyone has to be on board. From stakeholders, to clients, to your dev team and your management team, everyone must contribute accordingly to ensure that the results are delivered on time and on budget. If collaboration and communication are your key strengths, this is a perfect method to execute a successful project.

If you’ve got a client who isn’t interested in providing any feedback or doing testing, and Agile Methodology is probably not going to work — Waterfall will be your best bet. Likewise if you have a client who is chomping at the bit to be involved and wants to play with their new toy an Agile process is the best option for them.

Can anyone apply this?

So these methods work for us in the dev space — but what about you? What if you work in construction, education or the beauty industry? We think both project management styles do have value in a variety of industries outside software development. The main reason behind this rationale is that both project management styles require active listening and problem solving for your client.

With Waterfall, you’ve got to ensure that you have listened to your client you’ve started any work to ensure that you’ve got everything covered. Waterfall means you’ve got to think of the finished product from all angles, and critically think on where problems could come up — and how you’d solve them before they happen. We think this is a great consultation process that helps your client feel heard.

This makes sense especially in the construction industry, as a building often has a fixed deadline which can’t really be moved. Not only that, the main structure will stay the same for a long period of time, and updates will be done in minor ways throughout the life of the building — like renovating a bathroom. Not only that, when you’re building, you can’t go back and change things quickly. You’ve got to think about not only what the client wants and best practice, but things like how tall people are — will your door frames be high enough? How will natural light affect how much of the air conditioner needs to be used? Can the carpark handle bigger cars?

Waterfall is an excellent management strategy as it requires little training for your staff. If they know how to do a particular task, that’s the task you’ll deploy them to on this project. In Agile, employees have got to be more… well, Agile — hence the name. Waterfall puts the pressure back on the Project Manager to get the structure right from the start, so their staff can run with it.

Agile is a great tool for small teams that are Swiss Army Knives, and you don’t have a hard deadline — and you’ve got a client that is super eager to be involved and provide meaningful feedback.

Even though Agile doesn’t need as extensive planning as Waterfall does, it still requires a lot of intuitive thinking and looking at each stage from your client’s perspective, aiming to have something that’s pretty close to their expectations once you present it to them.

Agile is being used more and more in industries beyond software development — we’re about to roll it out at our sister company bellette which does all things creative. One of the industries that we would love to see this implemented in would be the not-for-profit industry. The not-for-profit industry traditionally runs lean on cash and volunteers, making it difficult to think big when budgets and timeframe resources aren’t consistently available.

The use of an Agile approach would allow not-for-profits to work in short bursts of funding cycles, allowing a snowball effect to occur within the organisation. It means they can create action in the present moment, follow the changing needs of their target market — and reach potential new donors in the process.

These are just two of many project management methodologies that are used within the software development industry, there’s many more not just in software development, but in the wider project management space. We recommend that everyone takes a moment after reading this blog to think about how you do business and how you can better serve your clients and empower your team. Empowering your team and clients is a value we believe should be at the core of all organisations, and executed in the desired project management tool that you chose to achieve this goal.

Originally published at https://www.hutsix.com.au on December 11, 2020.

--

--

Erika Hamilton

i have a lot of feelings and the internet is my home