Whether you are a software developer or a tech enthusiast, you are probably familiar with Agile methodologies like Scrum, Kanban, FDD and others. The Agile approach is a well-known and established methodology used by business in industries like software and product development, manufacturing and construction.
Different Agile methodologies have grown in popularity since the early 2000s thanks to their proven ability to ensure a speedy and continuous delivery and enhance collaboration, flexibility and real-time feedback.
In this blog post, we will explore the early years of Agile and its benefits, and take a look at the most popular and widely adopted methodologies and best practices.
A brief history
The early years of software development were characterized by a growing number of software companies that developed and introduced products through unplanned and lengthy processes. Using these old processes and approaches to deliver products to end users can take months or even years.
Development teams at the time had to identify the needs; define the project requirements; design, develop and test the product; fix bugs & vulnerabilities and introduce a product in its entirety to the client. One of the most popular approaches that followed this model was the waterfall approach. As its name implies, the waterfall approach followed one unique direction, which meant that adapting to changing needs or making additions would not be possible. Each team had to complete the tasks in hand in order for other teams to take over. Prioritizing the development of an entire product at once without the necessary flexibility made the finished solutions outdated by the time they were introduced into the market.
Furthermore, a lengthy development process meant more costs, which made products more expensive – something that didn’t appeal to either software providers or their clients.
The frustration with old project management techniques pushed software providers to find effective and fast ways to introduce new products and features into the market. To achieve this goal, 17 developers – aka the Agile Alliance – met at The Lodge at the Snowbird Ski Resort in Utah on February 11–13, 2001. The outcome of the meetings was the development of the Agile Manifesto. The manifesto consists of four main values and 12 principles that put collaboration, human interaction, efficiency, quality and client needs at the forefront of the methodology. Additionally, Agile was designed to significantly reduce the time spent developing new software versions and releases by adopting short periods of work also known as sprints.
Benefits of the Agile methodology
Adopting Agile methodologies and best practices comes with a number of benefits as they allow development teams to:
- enhance collaboration between different teams and individuals involved in a project (product management, design, development, QA, stakeholders, etc.)
- increase efficiency by delivering solutions and products faster without undermining quality
- control costs as sprints have a predefined duration
- Prioritize the most important features and allocate resources accordingly, thus delivering greater business value to clients
- promote visibility and transparency within and between teams and stakeholders
- gather feedback quickly from end users
- adapt to change in needs and user stories.
Different Agile methodologies
Ever since the introduction of the Agile Manifesto, sub Agile groups and approaches have been developed to respond effectively to specific needs, businesses and industries. Although these different methodologies differ in terms of processes, specific roles and terminologies, they still follow the same basic principles of delivering quality solutions in a timely manner. Below are the most adopted Agile methodologies.
Arguably the most known and widely used Agile methodology, Scrum is a software development framework created in 1992 and designed to help development teams deliver software within short periods of time or sprints of between two and four weeks.
Scrum development consists of four major components: the scrum team, events, artefacts and rules.
- The Scrum team: According to the state of the scrum report, the average scrum team comprises five to nine people. The team usually consists of a product owner (represents the client and conveys the vision of the project), a scrum master (responsible for overseeing the whole project and making sure the development team has the optimum conditions to deliver) and the development team.
- Events: Five major events are held during a sprint: sprint planning (a kick-start meeting in which the different parties discuss the scope of the project and how the work will be achieved), a daily stand-up meeting (a short meeting in which team members discuss their progress and planned tasks), a sprint review (a demo in which team members present their work), a sprint retrospective (where employees discuss what went well during the sprint and what issues need to be addressed) and the actual sprint. These events aim to improve team communication and collaboration and ensure everyone is on the same page regarding the project.
- Artefacts: Scrum artefacts give both scrum teams and stakeholders key information to understand the project under development as well as planned and completed activities. The product backlog, sprint backlog and product increment represent the three main scrum artefacts. The product backlog is a document containing a detailed to-do list of the existing features, requirements and work items needed to achieve the project’s objectives. The product owner is responsible for the product backlog. The sprint backlog, on the other hand, is a list of the items derived from the product backlog and should be completed within a specific sprint. Finally, the product increment is a collection of backlog items that have been completed.
- Rules: There is no one-size-fits-all strategy when it comes to scrum rules. Rules are determined by the scrum master, who assesses the needs of the project and the available resources so as to determine the rules to follow during a sprint. Some examples of rules are related to the duration of sprints, stand-up meetings, reviews and retrospectives.
Lean software development (LSD)
Lean software development is an Agile methodology invented in 2002 that allows teams to deliver quality and high-value solutions to clients according to the principles of lean manufacturing. Within a lean environment, the focus is on specific valuable features or products that are prioritized for development within small batches. Similar to Scrum, the lean approach follows the 12 principles of the Agile methodology by promoting collaboration, client satisfaction, real-time feedback and quality and frequent delivery.
The main principles of LSD include the following: eliminating waste or anything that doesn’t add real value to clients; creating knowledge by documenting, retaining and sharing valuable learning; deferring commitment by gathering the required information needed to make decisions, which otherwise translates into late decision making; fast delivery and, of course, respecting the team.
Kanban is a visual workflow management approach that focuses on flexible planning, frequent software delivery, transparency and continuous learning. In Japanese, Kanban roughly translates into English as ‘sign boards’ or ‘visual cards’ and was first introduced by Taiichi Ohno (industrial engineer and businessman) for Toyota Motor Co. in Japan in 1940. Kanban was introduced to the IT world by David J. Anderson following a Microsoft project conducted in 2004 that followed the same principles. In his book Kanban: Successful Evolutionary Change for Your Technology Business, Anderson describes how generalizing Kanban principles and best practices into a visual system can be used by a variety of teams to enhance collaboration and efficiency.
Not necessarily iterative like Scrum and other Agile methodologies, Kanban has a sequential and longer, yet flexible, approach.
Easily the simplest of Agile methodologies used today, Kanban is based on three basic principles:
- visualize what you’ll do today (workflow automation) – organize and segmentalize tasks within Kanban boards which specify the progress of the project from backlog and then planned, to in progress, developed, tested and completed;
- limit the amount of work in progress (WIP) – limit and balance the workflow to help teams commit to specific tasks and avoid work overload;
- enhance flow – prioritize important work when teams complete the tasks in hand.
Feature-driven development (FDD)
Feature-driven development is a client-centric, short iterative approach first invented in 1997. It is based on software development techniques and principles such as developing by feature, code ownership, etc. Features form the essential pillars of FDD, as is the case with user stories and Scrum.
A typical FDD project life cycle starts with the development of an overall model that will result in an object model and a series of notes that will help users identify and understand the fundamentals of the project. The second step is to develop a feature list containing small and valuable features that don’t take more than a couple of weeks to build. The third step is to plan, by feature, where class and set feature owners are identified. The fourth and fifth steps of the project are where roughly 75 percent of the project workflow is designed and built by feature. This is where the design package is completed, adding more content to the initial object model and the feature is completed. These two stages include tasks like modelling, design programming, testing, and so on.
To summarize, the table below compares the Agile methodologies as whole with the other, older development approaches, by applying a number of criteria.
|Criterion||Old project management approach (e.g. Vee model, spiral model, waterfall model)||Agile approach (e.g. Scrum, LSD, Kanban, FDD)|
|Development model||Life-cycle model||Evolutionary delivery model|
|Planning scale||Long term||Short term|
|Requirements||Defined at the beginning of the project||Adapts to evolving needs|
|Team size||Departments||Cross-functional teams|
|Interaction with clients||At the beginning of the project and at specific milestones||Frequent|
|Testing||At the end of the project||Continual testing|
|Documentation||Detailed and through||Only when needed|