Agile is an approach to managing projects that can be used for virtually anything. However, it was founded in software development and has been adopted by many businesses over the traditional waterfall method. The following is a basic guide to understanding and mastering the agile method.
The waterfall method
The traditional process of development in the past has been the waterfall method. This model is a non-iterative (sequential) design process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of requirements, design, implementation, verification and maintenance. This means that only once each stage is complete can the developers move on to the next step.
The waterfall method is not ideal as it poses many disadvantages over the agile method:
- Developers can’t go back to a previous stage and make changes once a step has been completed
- This methodology relies heavily on initial requirements.
- If a requirement error is found, or a change needs to be made, the project has to start from the beginning with all new code.
- The product as a whole is only tested at the end which means if bugs are written early but discovered late, their existence may have affected how other code is written.
An overview of the agile method
Agile involves breaking down larger projects into smaller, more manageable chunks called iterations. These smaller project pieces or iterations are completed during sprints (a sprint is a set amount of time where the work is accomplished). At the end of each iteration, something of value is produced and should be able to be put into the world to gain feedback from users or stakeholders. Agile is advantageous as it has designers, developers and business people working together simultaneously as opposed to the waterfall method where you don’t start design until research is done and you don’t start development until the designs are signed off on.
The key to mastering Agile development
There are many essential things to consider when trying to master the agile method. However, the three things to mainly focus on to ensure successful agile project management are:
- Communication – Any project benefits from good communication, as do agile projects
- Dedicated teams – Agile works best with a dedicated team of people who are willing and want to collaborate. The better the collaboration, the better the product.
- Good planning – For an agile project to succeed, it requires good planning. It is important to be thinking through the project ahead of time, coming up with a robust project backlog and estimating features as best you can.
The following are the twelve principles of agile development as taken from The Agile Handbook by Philosophie (http://agilehandbook.com/agile-handbook.pdf):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Welcome changing requirements, even late in development. Agile’s processes harness change for the customer’s competitive advantage.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximising the amount of work not done — is essential.
- The best architectures, requirements and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The Agile Lifecycle
There are many variations of the agile methodology and it is important for your team to come up with the process that suits them best. Characteristically these processes follow a short life cycle which is repeated during each iteration. A popular variation of agile is the scrum methodology which we will be focussing on in this basic guide. Scrum focuses more on the management of the project as opposed to on what is accomplished. As previously mentioned (scrum) projects are broken down into smaller, more manageable chunks called ‘iterations’ which take place over a set interval of time called a sprint (generally one to three weeks). The lifecycle of each sprint includes the following:
User stories define everything potential users want to do on the project. They are defined for each of the user groups on the project and are structured like:
As a [type of user]
I want to [do this thing]
So that I can [accomplish this goal]
Each scrum project begins with a meeting, this first meeting is as extensive as possible as the initial project backlog needs to be created and the project team introduced. Before each of the future sprints, there is also a sprint planning meeting. In the first “kick-off” meeting it is important to cover an overview of the project and the goals, who will be working on the project, determine the point person for client sign-off, create the project backlog, determine which feature to work on and get everyone on the same page.
Every project will have a project backlog. This is a list of all the product features which are typically defined by user stories or features. These stories are then ranked by priority using a scale from one to three. The project backlog can be tracked using an analogue method such as post-it notes or can be tracked digitally using a software solution such as Trello.
It is important to remember that the project backlog is always fluid and never locked in. The only exception to this rule is during a sprint. While a sprint is in session, it is important to not add any features so that your team remains focussed and the project can be properly tracked. Once all of your user stories have been determined, they must next be ranked by priority. The project lead will be in charge of reprioritizing the backlog between sprints and if new features are added or requested by users, they are encouraged to be added to the backlog.
It is important to estimate how long each user story will take so that you are able to estimate what can get done per sprint. One of the major challenges in development is accurately predicting how long things will take to get done. Hence, agile methodologies use relative estimation to rate user stories. As previously mentioned user stories are ranked on a scale of three. If something is particularly challenging and you are struggling to rate it on the three point scale then it should be broken down into smaller features that can each be ranked on the scale of one to three.
Ranking each feature also helps you determine the team’s sprint velocity which will be discussed in the subsequent section.
A sprint is a set amount of time where the work is accomplished. Agile projects are broken down into small, consistent time intervals (sprints). These sprints are typically not longer than three to four weeks and be as short as a few days.
Feature estimation is used to determine the team’s sprit velocity. Sprint velocity is how much work a project team can get done per sprint. It is typically used to estimate how many features can be accomplished each sprint (based on the feature points). The velocity is average over time and the more sprints you do, the more accurate the sprint velocity estimate becomes.
Before the start of each sprint there is a sprint planning meeting which is often combined with a sprint review meeting for the previous sprint which may have just taken place. In this meeting the goals for the upcoming sprint are established. The project features for the sprint are reviews and using the team velocity these tasks are then ordered in the backlog to try optimize the upcoming sprint.
Every morning of the sprit a short meeting is held (this meeting is usually less than fifteen minutes). This meeting takes place at the same time every day and includes everyone on the project. During the meeting everyone takes turn standing up and answering the following three simple questions:
- What did you do yesterday?
- What are you going to do today?
- Do you need any help or are there any blockers in the way?
These meetings help everyone remain focussed, allows for complete transparency and makes sure that everyone is accountable for what they say they will deliver. The results of this meeting are typically shared with the client. This daily communication makes sure that if something is holding up the team, they can get a response quickly.
The sprint review meeting brings together the project team and other project stakeholders such as the client to present the work that was completed. The review starts with a functional demo, followed by a conversation as to how the product could potentially be improved and if there needs to be any reprioritizing of the project backlog. After this the team can collectively plan out their next sprint.