The language of software development can be difficult to understand - not only because of technical jargon, but also due to the long list of methodologies and approaches to running software development projects that have been developed over the years. You’ve likely heard of Agile, Scrum, Kanban, and many other examples. In this article, we focus on Agile and Scrum: what these terms mean and what business implications they can have for your project.
The first thing to establish is that Agile and Scrum are closely related. In fact, you can use both for your project and benefit from it. You know how every square is a rectangle, but not every rectangle is a square? That’s pretty much how it works for Agile and Scrum: Agile is a methodological approach to software development, while Scrum is a practical way of implementing it. You can use Agile without Scrum, too - there are other equivalent practical solutions to choose from - but you can’t use Scrum without being Agile. (Scrum is the square in our little analogy.)
The methodology - Agile principles
Agile was introduced by a group of progressive thinkers who had had enough of the waterfall approach to software development. They came up with the Manifesto for Agile Software Development, emphasizing the importance of each individual member of a development team, and putting value on working solutions and good collaboration with clients. They believed that a good software development process should be able to cope with change - market shift, unexpected user expectations, changes to the budget, and other factors that can throw a wrench into any plan.
That’s Agile in a nutshell, but to really understand the approach, it’s good to familiarize yourself with the twelve principles behind the manifesto. Here they are, paraphrased for brevity:
1. Prioritise making the client happy by delivering valuable solutions early and often.
2. Be open to changing requirements and use them to the client’s advantage.
3. Deliver working software iteratively, preferably in smaller but more frequent packages.
4. Cooperate with business stakeholders every day.
5. Build a motivated development team, provide them with support and trust.
6. Choose face-to-face communication whenever you can.
7. Measure your progress by how well and how completely your software works.
8. Maintain a sustainable development pace for stakeholders, developers and users.
9. Work to achieve technical excellence and good design.
10. Maximize the amount of work not done (simplify processes).
11. Allow the team to self-organize.
12. Evaluate your own work regularly and use your observations to improve your work.
These principles are the backbone of Agile. It might not be possible to always follow all of them to the letter, depending on the project, but good Agile teams know their roots and keep them in mind throughout development, to the great benefit of their projects and clients.
The implementation - Scrum in practice
Scrum is a practical framework for implementing the Agile methodology. It introduces concepts such as iterations with a set duration and specific roles for those involved in the project. Usually, iterations in Scrum are called sprints. They are usually a week or two weeks long. Their purpose is to allow development teams to deliver software often, which is both great for morale - everybody loves seeing the product grow - and for project planning.
Each sprint is planned in advance by the team and stakeholders. The Product Owner (more about roles in a moment) makes a list of high-priority tasks, and the team identifies the one they can complete during the next sprint. The tasks left for later are transferred to the product backlog, which contains all of the features the finished product should have. The main benefits of this approach are that it divides the work into manageable, complete chunks, and that it allows for late-stage changes to the product. It’s easy to remove a feature from the backlog if, say, user feedback indicates that it’s not necessary. Teams can prioritize features that users want to see. Even big changes to project scope are pretty easy to manage with Scrum.
Another important aspect of this framework is the organization of work. Teams that follow Scrum practices do a daily stand-up meeting that lasts about 15 minutes. They discuss the goals for the day, and any issues or problems they encounter. This allows them to stay on track and keep their goal in sight. At the end of each sprint, a demonstration is held to present what the team has accomplished. Another regular post-sprint meeting, the sprint retrospective, allows the team to reflect on what they’ve done well, and what could be improved in their process. They base their conclusions on very practical observations they made during the past sprint, and use them to improve the next one. It’s a great example of using all of the available resources and knowledge.
Roles are a very important aspect of Scrum. There are only three: the Product Owner, the Scrum Master, and the Scrum Team. The Product Owner is responsible for maintaining and communicating the vision for the product. They keep track of what features need to be introduced, and of (ever changing) business and market requirements. If they do their job well, the project team remains motivated and works in alignment with project goals.
The Scrum Master’s role is to manage the organizational aspects of Scrum. They schedule meetings, identify challenges and help clear bottlenecks. Together with the Product Owner, they manage the product backlog and tasks for each sprint. The Scrum Master also keeps track of the team’s everyday work, making sure everyone follows Scrum practices as intended.
Finally, the Scrum Team are the people who get their hands dirty working on the product. These are the developers, designers and testers, working together without dividing themselves by skill, but focusing on the tasks they need to complete by cooperating with each other. They are the ones deciding how much work they can complete during each sprint - after all, they know their own capabilities best.
The benefits of Agile
Alignment with goals
The entire focus of the Agile approach is on product goals. The development team understands what features are necessary and why, what kinds of users will interact with the software and what their needs are. This knowledge allows them to create solutions optimized for a very specific purpose.
No need for a set-in-stone end goal
Agile welcomes change, so it’s not a problem to do a sudden pivot in the middle of the project. Sure, it might take some adjusting and a few lines of code might need to be scrapped, but overall it’s much easier to deal with change in an Agile project, than in one using the Waterfall approach (which involves creating a strict development plan ahead of time and following it closely).
Improvement and market fit over deadlines
Deadlines can be stretched as needed (e.g. by introducing an extra sprint) if a change in requirements makes that necessary. It’s also easy to prioritise particular tasks in Agile, to create a working MVP and build up from there, while gathering traction and user feedback.
Good post-release life cycle & support
An Agile project doesn’t end the moment it’s shipped. Usually, there are still lower-priority features to implement, so the team stays closely involved and ready to introduce fixes, should an issue appear.
Good collaboration
Agile teams work closely together, using their cumulative knowledge and experience to meet business goals. This means that designers communicate with developers, and both groups cooperate with testers - all to make sure the product will delight users and be a success for the client.
Fast, high-quality delivery
Agile teams generally work in sprints (whether or not they use the full Scrum framework), and they decide what tasks they are able to complete with each iteration. This means that they deliver complete solutions, working at the optimal speed, giving themselves time to problem-solve and test extensively.
Focus on client/user needs
As already mentioned, Agile teams understand the client’s business to some extent. They think about the product’s business goals and market fit, they learn about users’ behaviour and needs. This helps them deliver tailored, effective solutions.
Continuous improvement
A feature delivered during one sprint can be improved upon in another sprint. More importantly, the product is like a living organism in Agile - it grows, and as it does, users can interact with it, letting the development team know where the product falls short. This allows for constant improvement based on actual user feedback.
Benefits of Scrum
Emphasis on collaboration
A Scrum Team doesn’t divide itself into developers, designers and testers. They are all experts in their fields working towards a common goal, using all of their knowledge and experience. And as they all understand project goals, they can more easily make good decisions when choosing their approach or tools.
Improved motivation and accountability
Understanding the vision for the project greatly improves engagement. Moreover, daily stand-ups help the team communicate their problems and get help if they need it. There’s also no room for slacking off - it’ll be immediately noticed if someone gets stuck on a simple task for days.
Dependability and predictability
Everybody knows and follows a strict schedule, with daily stand-ups, as well as sprint planning and retrospectives. They know in advance what each sprint’s focus will be, who’s going to be responsible for what, and when they can expect a particular task to be delivered. This can be especially important for tasks that have to be completed in a particular sequence - in a well planned sprint, there’s no idle waiting for the completion of someone else’s task.
Transparency
Everyone knows what everyone else is supposed to be doing. This includes the Product Owner and the Scrum Master, which helps them plan better and manage project tasks more effectively. It’s also easier for the client to check on the project’s progress.
Conclusions
As we’ve established, you need Agile to use Scrum, but you don’t have to follow the Scrum framework to be Agile. Both approaches bring a number of benefits (to the project team and the client’s business). The advantages of Agile apply to Scrum, too. Overall, we believe Agile and Scrum make for a good combination and a solid toolset for most software development projects. Scrum is like a power-up for Agile, and even if you don’t commit to follow the Scrum toolkit to the letter, you can use elements of it to solve specific challenges and improve your team’s development process.
There are many other options to choose from, of course. Kanban, for example, is another framework for Agile - one based on visually pushing tasks through a series of stages on a task board. Kanban is great for introducing incremental changes and it’s very easy to introduce to an Agile team.
The Waterfall approach, on the other hand, is almost the exact opposite of Agile. It’s a structured process that divides development into stages that need to be completed in order. Because of this linearity, Waterfall is much less flexible than Agile - but it is more predictable and can make budget planning easier. While we don’t recommend Waterfall for smaller projects and young companies, it can be a great approach for large corporations that need a well-documented and strictly organized process.
If you’re still not sure whether Agile or Scrum are for you, we’d be happy to offer our advice. At iRonin, we believe in using the right tools for the task, which means adjusting the methodology and framework to fit the project, not the other way around.
Let us know if you’re considering using Agile for building your app. iRonin’s experts follow Agile principles and have a lot of useful know-how.
