It’s been years since Agile software development became so popular. Still everyone has their own understanding of what Agile exactly is. Many people consider it a methodology. We don’t. We believe it’s an ideology.
What Agile Is – And What It Isn’t
The Agile Manifesto includes 4 main ideas, not techniques. It is based on 12 principles, but they all point to ideology. None of them talks about or even looks like a methodology.
Agile isn’t a magic wand. But some people still believe that it can improve software product development process within a short period of time (say, a couple of months). Some people even think that Agile principles mean no planning and no documentation, or that it’s better or worse than Waterfall, and keep comparing the incomparable, pointing at advantages and disadvantages.
However, if we take a look at project management statistics, we’ll see that things are never black and white. Only about 18% of surveyed software development companies mention pure methodology. Others say that they use a hybrid, some lean towards Agile, some towards Waterfall, but it’s always a hybrid.
If you want to make your software project flow faster and with less wasted effort, there’s a variety of project management methodologies that you can use.
Main Questions To Ask Yourself When Choosing The Best Methodology For Software Development
We gathered a few criteria and matched them with different methodologies. These are the questions that you need to get answers to before deciding which lifecycle method should be used for your own software product.
• How stable are your product requirements?
One of the biggest characteristics that dictate the choice of a lifecycle method is the clarity and stability of software product requirements. Frequent changes in these requirements—after the software project has started—can hinder your progress. In such cases, choose the iterative approach, because it provides an opportunity to accommodate new requirements even after the project has been started. However, if you are able to complete the set of requirements before moving on to the next phase, Waterfall could be your choice.
• Who are the end users of the system?
A controlled group of end users who can greatly influence on the project can help you define requirements and manage changes together with your software development team. This means you can achieve stability of the project requirements and allow you to use the Waterfall approach. However, if your end users are distributed, you are likely to have a wide range of requirements. You cannot prefer one feature over another until the end users use the system and start giving feedback.
• What limitations does your project have? Is it Timeline? Is it Budget?
Time matters. Flexible time limitations mean flexible approaches to project management. And vice versa, if you have fixed deadlines, it’s better to proceed with more traditional approaches. As for the budget, it’s actually a great tool that helps you to determine how you should manage your software project. For instance, if your budget allows just feature implementation and you need to direct your attention at prioritization, then your software development team most likely won’t have time for extra code review and sprint planning.
• What is the size of your project?
If you have a small project, usually it has a small fixed budget as well, and there is no need for modern best practices of Agile. On the other hand, if your project is complex, you should think more about improving the process day by day. You should get higher efficiency and productivity from your team after a few months. Then, of course, you should choose more flexible practices.
Bigger projects require involvement of more people and better clarified requirements: it means that you should spend a lot of time at the early phases. But it doesn’t mean that you should ignore Agile frameworks for building intermediate processes. Your software development company will take care of that.
• What type of contract do you have?
Fixed-price contract presupposes Waterfall or RUP methodology, supported by fixed requirements and clarified acceptance criteria. Dedicated team contract is for more sophisticated cases. You should think about coordinating the work of your team members. You should have positive influence on their motivation and daily productivity. If you use software outsourcing model, dedicated team may be a part of a distributed team. It is highly important to establish coordinated work between them, to avoid misunderstandings and development gaps. There are several popular project management frameworks that will help with it. At the same time, dedicated team model has short delivery cycles, and for each cycle, separate estimates are provided by your team. And you are free to pick any framework.
• What kind of project do you have from the business perspective?
Is it a startup, an enterprise project, or do you need a support team for your internal software project?
A Startup requires quick reaction, fast core implementation, delivery of MVP (minimum viable product) in short iterations under high pressure.
The main challenge of Enterprise projects is the complexity of the existing business. There are two main purposes: to define what must be delivered as expected, and to improve the daily process of implementation.
Internal Business Support projects usually don’t have to run so fast. You can have a supporting team that covers all urgent issues concerning your software product.
Our experience shows that for startups and enterprise projects a dedicated team is the most effective solution that solves the problem of continuous software product delivery. Unless you have a relatively small project with fixed requirements for a stable market, your way is the Agile way. And most importantly, it will be a hybrid pack of best practices and methodologies that work well together with your own business processes.
A Real Life Case: A Software Development Project
One Client addressed our company with an existing iOS product that had already been on the market. They wanted the same product for Android—with additional features that came from their end users as suggestions for an upgrade. It was a medium-sized project had a strictly fixed budget, and, most importantly, strict deadlines, which were dictated by the business strategy of the startup. The Client wanted a fixed-price contract with prepayments for each stage and only after the successful delivery of the previous milestone.
So what did we decide to use for this project?
- Waterfall as the basic approach. We prepared a plan of each delivery with deadlines.
- The 1st iteration was fixed for defining additional requirements, preparing Acceptance Criteria (RUP, Waterfall), and a detailed Risk Analysis (Spiral).
- Prioritization of backlog, filtering features for MVP (RUP, SCRUM).
- Kanban as the internal process: a board, speeding up software development and avoiding downtime, daily meetings (SCRUM).
- Critical path as the criterion of task order.
- Code reviews for high-quality code delivery (XP).
- Demo after each milestone (SCRUM), delivery of the product according to the Acceptance Criteria.
The software product was delivered successfully, on time and on budget. The entire scope was implemented, and some more things were added for good measure. There were change requests that were conducted during additional iterations. What’s more, our new Android version had higher quality than the original iOS application. The atmosphere in the team was kept stress-free and friendly, end users were happy with the product, and so was the product owner.
There’s one more secret that helped our company achieve this: no matter how many benefits an approach brings, it always has dark sides, and you must know them to avoid them. Let’s take a closer look.
Dark Sides Of Agile Software Development
They are often rooted in human mistakes. The good news is that we can prevent or fix them. We only have to know where the good method ends and the dark force takes control. Here they are.
• Daily standup meetings. No one feels right at such meetings, they hold no efficiency or productivity, so you shouldn’t waste your time and time of your team. Meetings must be effective, up to the point.
• Frequent change requests. They can kill your project, delay the main releases and deplete budget. Applicable to fixed cost projects.
• Non-professional influence on the product. It is related to active user involvement, and it can make your product heavy and non-friendly for the user. You should consider opinions of users, of course—but trust your expert when making the final decision.
• Frequent delivery. It draws attention from core features on delivery. Moreover, you need to plan additional one- or two-day buffer for each delivery date.
Choose Your Software Development Methodology Wisely!
We believe that Waterfall can be quite useful for the initial stages of product development – Business Requirements, Risk Analysis and UI/UX Design. When it comes to software development, a correct set of Agile methodologies and tools in the skillful hands of your project manager will help you. That’s why we give the final piece of advice: trust your project manager; this person is able to use the right tool for the right job and find the unique combination of suitable approaches and best practices. Just as unique as your project.
