Traditionally, projects have taken a sequential, step by step approach, starting with the gathering of detailed requirements, design, coding, system and user acceptance testing, bug fixes, and delivery. Lengthy review and approvals often need to take place too. Some benefits of this Waterfall approach are:
The main negatives are:
Agile addresses these problems:
But of course, there are disadvantages
In a world of rapid change and usually uncertainty in what we need to build, the reality is that we can't always afford long development cycles, for projects that may need to be scrapped and rebuilt later on.
A short summary, encapsulated as a manifesto describes the culture of being 'agile' It states that we value:
While there is value in the items on the right, we value the items on the left more. The principles underlying this are below. Click on each one to understand what the principle actually means.
Scrum and Kanban are the most commonly used Agile project management frameworks. Both place a high value on continual improvement, optimisation of the work and the process. Both are highly visible and keep everyone informed on what is being done and what is to come.
The key differences for each are:
Delivery TimelinesThe similarities are:
At heart, they both follow agile principles. Both methods use a physical or digital board where people move work between roughly three categories:
First of all, we need to accept that software or change needs to be done more quickly in order to either gain or maintain a competitive advantage. So does this mean that Agile is the 'winner'?
Agile is all about a set of values and principles, and being able to adapt and adjust; therefore to say that Agile is the only way is actually being anti-agile.
Waterfall projects might become fewer in number but how Agile we can be depends on how prepared the organisation is to change.
In order to improve speed to market, maybe a transforming organisation will break a big project down into mini-projects, each using a variation of waterfall, so that the traditional sequencing of phases is not actually that sequential.
Other ConsiderationsTo help us decide which approach we should use, consider the following:
Just because a characteristic tends towards Waterfall, think what might need to change to allow a more agile approach to be used. For physical location, video conferencing and teams that are dedicated to the task might mean that off-shore projects don't have to be Waterfall.
So to conclude, choose the best method for the project and organisation, but no matter which approach is taken, in the spirit of agile, do, learn, change. Become an agile organisation in increments if necessary.
One of the principles of Agile is the idea of self-organising teams. Unlike a traditional team, a Scrum team doesn't have a team leader to make the crucial decisions and solve all the problems. Instead, the Scrum team as a whole decides how to overcome the challenges.
A Scrum team consists of a Product Owner who usually represents most stakeholders, Devs (Development Team), and a Scrum Master. There are also other stakeholders who are called upon as and when needed.
There is a hierarchy of understanding, with various levels. For simplicity lets start with the vision, which should act as the direction for all other activities. There are other ways of collating understanding but but the most important are the following four.
The product vision should serve as the guiding light to everyone in the team. It states the desired future state and supports the Product Owner in prioritising the features to be built first.
It needs to identify the goals, the customer, and why the product is needed. It needs to be unambiguous and realistic.
In my experience, the vision is often not very well communicated. Project members who work at a level of detail down in the hierarchy make fantastic efforts but its a bit like driving at 100mph in the fog.
An epic is piece of work that can be broken down into smaller tasks called 'user stories' or 'stories'. It allows work to progress in smaller pieces whilst maintaining progress towards a common objective.
A user story will focus on people / the customer, on what needs to be done, and why. The format is below:
As a [user role], I want [ability or feature of the product] because [the benefit/function of the feature].
It's a very short sentence written from the perspective of a specific stakeholder (there may be user stories for different stakeholders) a and will give the reader an instant understanding of the value that can be gained by doing the work. It doesn't need lots of detail. The principle of agile is 'just enough', and a user story acts as a placeholder, for follow up on the detail later.
Tasks break down user stories or other items in the backlog to a more granular level.
The user story creates understanding of what needs to be done or a software feature from stakeholder / user perspective.
As a [user role], I want [ability or feature of the product] because [the benefit/function of the feature].
If the format is not followed there will be risk that implementation is not done correctly.
I've seen these mistakes far too frequently. In fact it's more usual than unusual to see them. Clearly, organisations have some way to go before they can be considered truely Agile.
Scrum is comprised of Sprints, which are fixed periods of time, each of which are typically between one and four weeks. The point to this is accomplish tasks in incremental pieces. Because each sprint is so short, it allows projects to cope with uncertainty and changing requirements.