How To Use Agile Effectively In Your Software Project
It’s been years since Agile 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
Agile isn’t a magic wand. But some people still believe that it can improve software development within a short period of time (say, a couple of months). Some people even think that Agile means no planning and no documentation, or that it’s better or worse than Waterfall, and keep comparing the incomparable.
However, if we take a look at statistics, we’ll see that things are never black and white. Only about 18% 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 projects flow faster and with less wasted effort, there’s a variety of project management methodologies that you can use.
Main Questions To Ask Yourself
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.
• How stable are your product requirements?
One of the biggest factors that dictate the choice of a lifecycle method is the clarity and stability of the requirements. Frequent changes in requirements — after the project has started — can derail 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. 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?
One of the most important thing in our life is time. Flexible time limitations mean flexible approaches available for taking. 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 project. For instance, if your budget allows just feature implementation and you need to direct your attention at prioritization, then your 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.
• 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. Sometimes dedicated team is a part of a distributed team. So it is very important to establish coordinated work between them, to avoid misunderstandings and development gaps. There are several popular frameworks that will help with it. At the same time, dedicated team contract has short delivery cycles, and for each cycle, separate estimates are provided by the vendor. And you are free to pick any framework.
• What kind of project do we have from the business perspective?
Is it a startup, an enterprise project, or do you need a support team for your internal business 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.
Our experience shows that for startups and enterprise projects a dedicated team is the most effective solution that solves the problem of regular continuous delivery of the product. 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
One Client came to us 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 main approach of work with the product owner. 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 the 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.
What were the results?
The project was finished successfully, in time and in 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 product. 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 us achieve this: no matter how good an approach is, it always has dark sides, and you must know them to avoid them. Now we are going to tell you about them.
Dark Sides Of Agile
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.
We believe that Waterfall is quite useful for the initial stages of product development — Business Requirements, Risk Analysis and UI/UX Design. When it comes to 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.