Last week, we talked about some of the time management techniques we recommend at Scale3C. In software development, it’s just as important to use the right project management technique to guide you through work.
Planning is the key to success.
The project management methodology you choose will dictate how the rest of the project will perform. This includes preparing, planning, monitoring and controlling the activities needed to finish the tasks.
When it comes to project management, there are a lot of choices and each comes with its own set of rules, principles, processes, pros and cons, and more.
One important thing to keep in mind, however, is that there is no “perfect” or one-size-fits-all methodology. Each project management methodology has its own requirements and practices, that make it ideal for a specific occasion.
For software development specifically, there is a lot of talk on how to guide development. Each development project and client are different. The differences range in the deadlines, time-frame, budget, and more.
This is why you need to think about the specific project requirements and goals before diving into it. In turn, this will impact how your coding sessions and developing your tasks will go.
The point of selecting the right project management methodology is to maximise the efficiency and reduce the use of resources and time in each project. In other words, you have to be efficient and effective in your operational activities.
The best way to do this is by shifting focus on your project goals and requirements beforehand.
To manage a project successfully, you need to choose the right software development methodology that will work for your specific project at hand.
Projects vary in scope and requirements, as do the methodologies we typically recommend.
So, to help you decide and effectively manage your project tasks and goals, we’re going to be looking at 5 important methodologies we typically use at Scale3C – give an overview of each, and then discuss how to choose the right one that’s suitable for you.
In this guide, we’re going to be discussing the following software development methodologies and give our thoughts on each:• Waterfall • Agile
• Kanban• Bonus tip • Choosing the Right Software Development Methodology
The waterfall methodology was the first modern approach to software development projects as a way to transform risky projects into a linear step-by-step process, with minimal risks.
Often also called SDLC (Software Development Life Cycle), this technique demands solid planning, having a well thought out vision and most importantly – doing it right the first time around.
The reason behind this mainly has to do with the era it was developed in. In 1970, the software development scene looked a bit different from today, and so did the management practices.
Though, since then, the method has evolved quite a bit.
Now, it consists of five main steps (cycles) and looks something like this:
Each step of the methodology represents a stage of software development and if done well, the whole thing should follow a smooth linear process – like a waterfall.
Typically, in a waterfall model, you first analyse what the problem is. This step involves breaking down the situation in terms of project goals, deadlines, and any other requirements that stand out. This way, you’ll know what to expect throughout the project beforehand.
Secondly, in the design phase, you start outlining the project policies and objectives. For each project requirement, try to have some kind of a solution planned out in advance. In other words, prepare for the work up ahead and have some general ideas on how you’re going to tackle your problems.
Then, while in development, you take the information from the previous stage and start working towards creating functional code or solution. The work here does not have to be perfect, as you can still come back to it later, but it should give you an idea of what the final product should look like.
After that, while testing, look back at the product draft, look for any defects and get them fixed. If necessary, go back a few steps and start over until you reach this step and everything’s working properly.
Finally, after that, the product goes live but the cycle doesn’t stop here. In the maintenance phase, once your code is live, be on the lookout for any tweaks that can be made to make it more effective and relevant.
This seems like a lot, but if you’re following the Waterfall steps accurately, you should have a good idea of what needs to be done, when, and how to get there from the beginning.
If you’re working on a project with a long-time frame with many users, you might want to consider using Waterfall for maintaining tight control over the development process.
While Waterfall is all about careful planning and looking ahead, the Agile methodology is the opposite in that it focuses on iteration and seeing what works and what doesn’t through trial and error.
Agile, as the name implies, focuses more on flexibility while developing a project and being open to change, rather than the requirements. In agile, these coding sessions are called sprints, and they last from 2 to 4 weeks.
The aim of the sprints is to clear out any high-priority tasks and deliver a draft product for customer feedback. Afterwards, the latest version of the product goes back into development with repeating iterations and sprints until it’s perfect.
According to the Agile Software Development Manifesto, the values of the methodology are as follows:
This accurately sums up what Agile is all about – being flexible within your work and learning from constant feedback. The final outcome is based on past cumulative outcomes of the sprints, and the development steps are as follows:
The steps look similar to those of the Waterfall, but the process and the values differ vastly.
Because Agile operates within quick sprints, you first want to get a sense of what you’re building and for who (planning) and then design experiments and/or potential solutions to your given problems.
Once you have an idea or a solution of how to resolve a problem, you build a functional prototype and learn from customer feedback. Look for specific comments on the features of the product, your software metrics, and how you can deliver the highest value features for your clients the next time around.
Finally, you repeat the cycle, conduct additional sprints and repeat until the final product is finished.
High customer involvement makes the agile software development model ideal for when quick communication is possible and the product needs to be done before a certain date. There is also less risk associated with the software because you’ll be learning from reviews each iteration and from frequent communication.
The Lean software development methodology is adapted from the Lean manufacturing practices and is now a separate subculture within the Agile community. The Lean principles are similar to Agile development, with a slight difference.
The seven development principles are:
Essentially, Lean seeks to eliminate anything that isn’t adding value and only focus on things that need to be done at the moment. For software development projects, this is a great way to focus and hone in on the tasks that need to be done as soon as possible.
Lean prioritises maximising customer value and following the system – the way the team operates as a whole.
If that sounds confusing, let’s break down the above principles to see if the methodology would be the right one for your software development project.
With lean, waste essentially means anything that does not add value to the customer directly. Such as useless meetings, developing tasks, documentation, and any kind of inefficiency at work (e.g. multitasking).
When trying to ensure quality, many projects end up creating waste instead through excessive documentation. In Lean development, everyone tries to maintain quality through constant feedback and reducing waste.
In addition to that, teams in Lean tend to create knowledge, so as to properly document and retain valuable learning. This is done through code reviews, pair programming, using the right tools, and more.
While doing so, Lean development principles also say to defer commitment, meaning, you shouldn’t get too attached to one specific way of doing things. Keep your options open and continuously collect information so that you can make a decision based on data. Be ready to make a decision late into the development process, if needed.
Next, to deliver fast, you should look out for signs that slow you down – such as thinking too far ahead, not taking care of emergencies as they arise, and how to work efficiently.
The next principle, to respect people, is one of Lean’s most neglected pillars. Because Lean advocates fast-paced software development, team members should also be able to handle conflict and any other work-related issues as a team. This principle applies to every aspect of the development – from overall communication to onboarding team members and process improvement.
Finally, to optimise the whole, means to go over the whole development system and see what could be made more efficient. Since the goal of the lean method is to deliver as much value as possible, you need to be looking at ways you can optimise the whole system for speed of value delivery.
Overall, for lean development to be successful, every member in the project has to be able to understand the process. While this method is still an agile technique, it introduces two important concepts to the equation – eliminating waste and improving the flow.
Scrum is another subset of Agile and is one of the most popular frameworks for implementing agile. This framework is an iterative software development model used to manage complex software and project development with longer iterations (1-2 weeks long sprints) to complete the assigned tasks.
This methodology follows a specific set of roles, responsibilities, and meetings that never change – focused on getting more work done faster.
There are three main roles in this framework: the product owner, the development team, and the Scrum Master.
Each day of the sprint, the development team holds a 15-minute Scrum meeting with the Scrum Master to discuss any potential roadblocks that might interfere with the project’s success. They also review the previous day’s work and plans for the upcoming day’s tasks, to ensure everyone is in sync.
The Scrum Master then links the team’s progress to the product owner to define requirements and solutions. Then, when the sprint begins, the Scrum Master helps remove any roadblocks that might arise.
In Scrum, each member has a predefined role, and follows the Scrum Master’s given timelines, requirements, and objectives for the development process. With daily meetings, the whole team knows who’s doing what, eliminating any misunderstandings and confusion. They identify the issues in advance and resolve them before it gets out of hand.
Overall, constant communication and feedback ensure everyone is aware of all the issues and changes as soon as they arrive. This, in turn, lowers expenses and increases development quality.
Kanban is Japanese for “visual sign” or “card” and the framework is a method to show the team’s development workflow visually.
The board is split up into different work categories (e.g status of a task), as opposed to role and each task is recorded on a card. These cards are then moved from one column to another (e.g. backlog, in progress, done) accordingly.
The Kanban board helps team members stay on the same page and identify what’s in progress currently.
Because the framework is visual, it’s easy to get an overview of the team’s progress at first glance, depending on the cards. These cards communicate the development status at a glance, depending on the column they are in.
Nowadays, software developers use the online version when it comes to Kanban boards – notably Trello.
When using Kanban for software development, it’s important to have your products and processes defined in advance, along with the deadlines. Ideally, team members should be able to only move a card once the previous task has been completed.
Kanban is an evolving, fluid model that increases flexibility and is easy to understand. Additionally, because each project and team development process is different – you can customise and manage your Kanban cards depending on your workflow process (which also is different for everyone).
For our own software development projects at Scale3C, we tend to use a mix of Scrum and Kanban methodologies.
We’ve found that when dealing with clients remotely, it’s best to have a system in place that allows us to keep track of the daily and weekly tasks as they come. As an added benefit, we can also share the current status with our clients so that they always know what we’re working on.
The cyclical and agile approach of Scrum, combined with the workflow visualisation through Kanban is a quick and easy way to get an overview of a project at first glance.
All in all, there are a lot of project management methodologies when it comes to software development, each with their own unique and niche uses.
Choosing the right project management methodology is critical to your team’s ability to successfully deliver projects on time and on budget.
Meanwhile, using the wrong software development strategy might lead you down the road of the tree swing dilemma.
To avoid that, you need to take a step back and first define:
Then, you might want to look at how frequently you’ll expect changes through the project development process. For example, if you’re going to be working on a web app development project where changes are going to be frequent, the agile and lean methods might be ideal.
Meanwhile, for projects where you predict stability and predictability – Waterfall model might work better.
Software development projects in their early days make ideal candidates for Scrum. If the project is new, there is almost no maintenance work to be done and the team can focus on delivering a new working feature each sprint. In that case, the team is committed to a couple of features each sprint, which they can deliver without any interruptions.
Finally, for projects with maximum flexibility and less cross functional teams – Kanban works best if the other methodologies have their limitations.
Regardless of the project management methodology you choose, it’s important to be flexible and ready to adapt on the go. If one project management doesn’t seem to be working for you, don’t be afraid to jump to a new one.
Although there is no perfect way of managing a project, by defining the requirements beforehand and assessing the main key components of a project, you can choose an efficient methodology based on the needs of your project.