Without a doubt, software development methods are the foundation of a successfully released product. That said, not all foundations are made equal. Nor are they flexible or adaptive enough to fit across the board.

The sheer volumes in which software engineering methodologies come only add salt to injury. Lean, Agile, Kanban, SCRUM, DevOps, and others are literally a small army of options one can’t wrap their head around a fair share of hands-on experience.

Why?

Well, most system development methodologies are similar in concept — they are designed to help make working software. The devil, however, hides in the details. Shifts in corporate culture, changes to business processes, management, and team structure are the bare-bone minimum your company will walk through when switching to a new development process.

With stakes as high, we feel the need to walk you through every detail and nuance.

The software development process in action

Here, at Mad Devs, we rely on the principles of agile software development. Being a service company, we value the ability to adapt and adapt to change while putting the client at the head of the table.

We encourage responsibility for the product in each development team member, and we rely heavily on communications with the customer. Continuous integration and automatic delivery speed up the development cycle.

What is agile development?

Generally speaking, agile development is an umbrella for a plethora of development methodologies: TDD, BDD, SCRUM, etc. It is probably best characterized by the structure of the workflow.

Agile teams work in short sprints that take between one and three weeks. Each sprint ends with a finished product.

Here’s an example that should illustrate the workflow for those of you who do not have a technical background. Imagine a car factory where machines build wheels, engines, gears, etc. to assemble individual pieces into a vehicle.

Agile development treats this process differently. We will release a pair of rollerblades. Then a skateboard, a bicycle, a motorcycle, and only then a car. This way the customer has more control. They can look at the finished product by the end of each sprint. They have the time to test concepts, introduce changes, and fix errors way before the “car” is 100% assembled.

That said, we understood the “why” of embracing agile development methodologies before thinking about the “how”. We have realized that we need Kanban to stay competitive in a volatile market. And we, like any other business out there are looking for the biggest bang for our buck.

And even then we realize that agile while working for us, might not be the perfect fit for a different business.

Without further ado, let’s take a look at the pros and cons of the most popular software development methodologies.

Agile: Pros and cons

The principles of agile make a lot of sense on paper. How do they fare in reality?

• Flexibility: Agile is great for those projects that wish to quickly adapt to market demand. Developments, requirements, and even developers are often switched and swapped for greeted efficiency. The problems you, as the client, need fixed ASAP are given higher priority.
• Risk management: The advantage of added flexibility leads to superior adaptability. Identifying an issue simply isn’t daunting anymore because anything and everything is fixable without the need to redesign the whole product. In simpler words, you get both scalability and the ability to react to change out of the box with agile software development.
• Superior quality: Agile development prioritizes smart design. QA is done before the development and the developers are following clearly designed use cases and user stories. This improves the overall quality of the product while eliminating the need to fix bugs in production (generally X100 more expensive).

With a lot to gain, are there any downsides to following the principles of agile?

• Poor documentation: Agile developers will prioritize working on a product over documenting their steps. This can permanently lock you into an IT vendor as a different team will not be able to grasp the project at a glance.
• Score Creep: Getting your hands on a working product after every sprint is a great boost to intelligent decision-making. That said, continuous feedback can lead to an ever-increasing scope of work as new features are introduced fairly casually.
• Time: Most believe agile boosts development speed. While this statement is true to an extent, the speedy delivery is not the cornerstone of the process (quick results after each sprint are not equal to a quickly developed product). Most lean teams prioritize quality over speed and, as such, they build processes around loops of design, QA, and development phases. Introducing a new feature into an existing project takes a lot of refactoring.

Companies that rely on the principles of agile software development:

• Google
• IBM
• Spotify

What is lean development?

Lean software development is an agile development methodology that is focused on eliminating waste, which, in the case of software development, is unnecessary work. First introduced by Toyota, lean development has been since widely accepted as a much more effective alternative to Waterfall.

Lean development follows 7 simple principles:

1. Eliminating waste
2. Designing products with quality in mind
3. Continuously learning
4. Delaying commitment
5. Lightning-fast delivery
6. Culture of respect
7. Automation and optimization

Lean development is an excellent choice for those companies that are operating in a competitive environment. If you value time-to-market delivery than the mindset of avoiding coding in unnecessary features, not logging in tasks for years to come, and designing with quality in mind is just what the doctor ordered.

Lean: Pros and cons

What are the greatest benefits of introducing lean principles into your business processes?

• Early bird: A smart choice of priorities allows your team to focus on the key elements of the product resulting in a much quicker time-to-market delivery.
• Motivation: Lean nurtures a culture of mutual respect. The fact that everyone in the team can affect the outcome of the development cycle increases their motivation and engagement.
• Working on a smaller budget: You can save a lot of money from something as simple as the elimination of waste. This is especially potent when outsourcing software development as you aren't just avoiding unnecessary work, but are free to swap between team members leaving only the people in critical roles working on the product at a certain stage.

Impressive, eh? Well, just like with any other thing software development, each benefit is a double-edged sword.

• Team-centric: Your product depends on the core team and their contributions. This may cause a series of issues if key members decide to switch jobs. In addition to that, the weight of responsibility can lead to people working long hours which, in turn, leads to burnout. Effective management of work-life balance is suddenly a challenge when it comes to lean development.
• Skill-centric: You can’t afford to work with anyone short of the coding rockstar status. These people will be responsible for making both technical and business decisions, so saving the budget on hiring more underpaid interns is not an option. Nine women can’t deliver a baby in a month.
• Decision-centric: A lot of people from the business side are paralyzed by anxiety when they need to make decisions on the fly. Lean does not tolerate bureaucracy and delegation don the chain of command. You’ll need to be as lean with your business processes as the developers in order to succeed. This shouldn't be a challenge in 2020 yet it very much is, especially when talking about large companies.

Companies that rely on lean software development:

• Intel
• Nike
• DropBox
• General Electric

Kanban

Kanban isn’t a development methodology per se, but rather a way of approaching scheduling in agile and lean projects. The methodology advocates the use of a board with cards - a Kanban - as a means of visualizing the workflow.

The idea behind kanban is that each member of the team knows who is doing what and at which stage.

A Kanban board is designed with the software development cycle in mind. Said board exists to manage the flow of features. It ensures that the number of new tickets AKA to-do features matches the number of delivered features.

Kanban: Pros and cons

Just like any other software development methodology, Kanban brings in a series of advantages as well as a handful of challenges. Let’s take a look at the pros first.

• Simple and intuitive: Kanban is probably the simplest project management methodology. A board with cards on it is clear and intuitive to everyone who sees it. As such, adopting Kanban is much simpler if compared to smoke other agile principles.
• Collaboration potential: Kanban is designed to improve the visibility of work well done across the entire team.
• Delivery in mind: Kanban does not visualize tasks we need to do. It illustrates the process and makes spotting bottlenecks in performance much more simple.

What about the cons then?

• Hard to keep track of in unattended: Kanban boards become piles of rubbish with the speed of light if not managed properly. You will need a team that’s dedicated to Kanban if you wish to succeed.
• Lack of timing: Kanban is great at visualizing a process. That said, Kards are barely an intuitive choice for visualizing timeframes.

Companies that use Kanban to manage their agile projects:

• VMWare
• Volvo IT
• Blizzard Sport

What is the Waterfall model?

Back to the roots, eh? Waterfall is the good old software development methodology we were so used to less than a decade ago. And it is still widely used even today.

Why?

The simplest answer is because it still works. Well, to an extent...

The Waterfall model owes its name to the strictly linear phases of the development cycle. Each project is composed of:

• Requirements stage: This is where the customer requirements are gathered and analyzed.
• Product design: This stage is divided into two sub-stages. The first constructs business logic and the other designs software architecture. Both are based on the overall software requirements.
• Implementation: If put simply, this is the stage where developers make the product.
• Verification: The software goes through Quality Assurance and Quality Control.
• Maintenance: The product is ready and released. Clients are using it, discovering bugs and unnecessary features, and the production team fixes them. The process of implementing fixes follows every step of the waterfall model to a T.

Waterfall: Pros and cons

The Waterfall model is like a massive corporate giant with age-old history. It is rusty, moves slowly, and yet it still is widely popular and makes a lot of money.

• Everyone is up to speed: Your team knows what they are supposed to do. Requirements are gathered, analyzed, implemented, and tested in the very same way they were a hundred times before.
• Time is a constant. You will have clear timeframes and well-defined deadlines throughout the entire development cycle.
• You know what you pay for: If you are developing a software project, you will know the scope of work after the requirements stage. No new features - no financial surprises. It’s as simple as that!

How about the cons of one of the oldest system development methodologies?

• The lack of scalability: Waterfall development typically encourages the development of software monoliths. Introducing a new feature after all the work has been done will surely lead to the system breaking as a whole. This means more time in QA and bug fixing rather than focusing on developing new functionality.
• The inability to respond: You will not be able to change the scope of work even if something critical has happened.

The lack of feedback: Your users will not be able to test and provide feedback until the project is finished. Then, if changes are necessary, we are back to con #2.

Summarizing software development approaches

Now that you understand how project development methodologies work, what would your personal take be? Would you prioritize speed, flexibility, and scalability over stability and clarity?

Previously published at maddevs.io