Mastering Agile Software Development
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 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:
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.
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:
The following are the twelve principles of agile development as taken from The Agile Handbook by Philosophie (http://agilehandbook.com/agile-handbook.pdf):
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 reprioritising 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 optimise 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:
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 reprioritising of the project backlog. After this the team can collectively plan out their next sprint.
