Blog: Agile Software Development

Over the last decade the Manifesto for Agile Software Development has revolutionized the tech world. Since then Agile became serious alternative to old-school approaches such as Waterfall. Today Agile remains a top methodology for software development. Many professional developers and their customers became fans when they saw the superb results, under constrained budgets, and within the shortest possible time frames.


How do Agile and Waterfall differ?

Back in 2000, the Waterfall paradigm and the Fixed Price model were the software development gold standards. Although still widely used, experience revealed a number of serious flaws. With Waterfall, for example, software development is based on, and entirely controlled by, specifications. This by the book approach makes the development process very rigid and inefficient.


In contrast, Agile aligns with the Time & Materials approach, and aims at minimizing risks by dividing the development process into short time-cycles called iterations that typically last from two to three weeks.

This flexible development methodology had been used even prior to the adoption of the Agile Manifesto, but only afterwards did Agile become widely popular.

The big idea behind the Agile Manifesto

Agile is not a single approach, but a family of development processes and practices combined into a single manifesto, which defines the core principles and values that help you in build a successful team. As a matter of fact, that is why the Agile methodology is perfect for outsourcing your project development to a dedicated team.

Agile minimizes risks by delivering a working product at the end of each iteration. An iteration is a small development cycle, which includes all the steps and tasks necessary for adding a short list of the new features. In fact, usually you don’t have a thorough plan of the whole project for 6 or 12 months in advance. Instead, you define and implement its core features during the first few iterations. After that, you describe and document only the parts that are developed in the current iteration.

This approach helps to avoid risks such as running over budget, missing deadlines, and not completing the planned features. No development approach can eliminate all risk, of course. Some risks, especially those specific to the project, you can plan for in advance. You can reveal other risks only when the project begins development.

Scrum: A favorite Agile methodologies

Scrum, one of many Agile software-development methodologies, is a project-management framework actively used in software development. In practice, Scrum is a set of principles that serve as a foundation for the whole development process. These principles let you develop a working piece of software with a high-value subset of features selected for the current iteration.

Let’s quickly run through Scrum terminology:

  • Sprint is a fixed-length iteration during which some product increment is being developed.
  • Product backlog is an ordered list of requirements for the product, sorted by their importance. It includes design, layout, development, and testing tasks.
  • User story or backlog items are elements of the product backlog.
  • Sprint backlog is a list of software features from the product backlog selected by the product owner.
  • A burndown chart shows the remaining work in the sprint backlog, and is updated daily (see the nearby example).

An example Scrum burndown chart

Each development team has its own techniques for estimating tasks chosen for the current sprint. One of the most popular techniques is Planning Poker. Under this system, no one can change the list of tasks selected for the sprint. At the end of each iteration, the team reviews their successes and failures, and only then chooses tasks for the next sprint.

With Scrum pre-defined roles are divided into two groups:

  • Chickens: Users, clients, sellers, managers, expert consultants
  • Pigs: Scrum master, product owner, scrum team members

The Scrum master facilitates the project, and he or she leads the iterations. During the sprint, the scrum master leads daily scrum meetings where each team member briefly shares what has been accomplished since yesterday, and what he or she plans to work on today. The aim is to keep all the team members updated during the iteration. That way if someone runs into a problem, it can be immediately addressed.

During these meetings the scrum master also tracks the status of all tasks and coordinates the development process. This helps the team to reach the final goal by the end of the sprint. Lastly, the scrum master provides feedback from the product owner based on the development process reports.

To make the development-status monitoring easier, the team creates a Scrum wall to visually track the tasks. Team members write down all current tasks on post-it notes, and then move them around the Scrum wall as their status changes from To do, to In progress, to Verify, Fix bugs, and Ready for release.


A Scrum wall helps the team visually track tasks

Working with the Agile approach

Applying Agile principles and values, like the Scrum method, creates a non-stop development cycle: planning, development, testing, release, product owner’s feedback, and back to the starting point. This helps to avoid a situation when, after six months of development, the deadlines are not met and the budget is overspent — with little to show for it.

No matter the development approach, however, success depends upon a strong and experienced team. You cannot, however, ignore the human element in every software development project. Developers, like all people, get sick, go on vacation, or switch jobs.

Finding a new team member takes time, and then it may take weeks or months for the new team member to get up to speed. During this time, the new team member will need extra help from other team members. They help him or her adjust as fast as possible.

Even when new members join the team, however, the Scrum method helps smooth the transition and minimizes potential problems, while also balancing out the workload and creating a coherent team.

How does the client benefit from the Agile methodology vs. Waterfall and its Fixed Price Engagement model?

Fixed Price Engagement has its own pros and cons. If teams who use this approach can meet their deadlines and stay within budget, it would be much easier for a client to go with this model with no need to constantly control both the budget and the end result. The client’s responsibilities would be very simple:

  • Describe the end product they would like to receive
  • Get an estimate from the development team
  • Approve the project plan and make payment
  • Accept the final product

Unfortunately, with this model problems surface to the client only at the final stage when development is complete:

  • The requirements were not clear so the product does not match the client’s original idea
  • Market needs and changes were not accounted for since new technological solutions become outdated within a year or less
  • The team started running behind the schedule at some point, but it only was discovered close to the final deadline

All this time the client, who is not involved in the development process, remains unaware of the project’s current stage, and what the already implemented features look like.

It’s easy to provide accurate estimates for some turnkey projects—a company blog or a promotional site, for examples. If the client’s portfolio contains plenty of these types of projects, the chances of successful completion are high even when working on a fixed-price basis.

Conclusion: Agile is the way to go

If a client wants to develop a small project with a clear and well-described idea, and good understanding of how it should work, then consider a Fixed Price contract with a Waterfall model. Such clear understanding is rare, however. More common is an unclear vision with requirements likely to change during development. You need to estimate all these features before the project starts. This means that you can discover overlooked details only during the development process. All of this increases the likelihood that estimates are wrong.

Agile development, in contrast, lets you create estimates for each iteration, making them more accurate based on the results achieved in the previous iteration. In fact, the Agile approach is perfect for clients who at the start of development are not 100% sure what the final product should look like. If that’s you, then give DB Best a call—we can help.

Share this...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn