Agile is a generic term for software development approaches designed to handle uncertainty and change. This is done by delivering iterations quickly and often. The goal is to produce working solutions that can evolve based on customer feedback and changing requirements. It is often contrasted with more traditional waterfall development methodologies where development flows through a series of phases. The next phase can only begin aft er the previous one is complete.
Why?
The problem with developing products using the waterfall approach is that you have to know what you want at the beginning and wait until the end to see the results. Unfortunately businesses, clients and users are often not sure what they want at the beginning of a project. Waterfall attempts to deal with this through change control processes but these can be complex to manage and difficult to feed into the development cycle. Web and app development is inherently more flexible than physical manufacture. It’s usually easy to create prototypes and develop new
versions which fits with an agile development approach.
What?
A pure agile approach doesn’t work all the time, especailly when it involves combining complex software systems, hardware and service components. Some of the key Agile development methods are:
Kanban means “signboard” in Japanese and describes managing a process by making the workflow publicly visible to all. Developers regulate their work by pulling tasks from a queue when ready.
A set of principles that help software businesses optimise their processes and development methods. The aim is to get products to market faster and with higher quality by delivering the minimal set of requirements often refered to as the Minimum Value Proposition or MVP.
Scrum is the most widespread and popular agile software development approach. It is a project delivery framework based on short, time-boxed, incremental, development releases called Sprints.
Adopts minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.
An approach based on short development cycles and taking various software development practices to extreme levels. The process advocates frequent "releases" which are intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
Using Scrum
Scrum is based on a series of short, focused development projects called sprints. These are time-boxed which means they must deliver by a set date. If necessary the scope is reduced to deliver on time. The deliverable from each sprint should ideally be something that could be implemented with incremental functionality.
There are three defined roles in the delivery of scrum projects; the product owner the scrum master and the team.
•The product owner is the voice of the customer with responsibility for ensuring the final product delivers customer value. Product owners compile and prioritise product requirements to create a product backlog.
•The scrum master champions and facilitates the scrum process, coaching the team and tackling any impediments (i.e. blocking issues).
•The team is a cross-functional group of, typically, five to nine people who deliver the product.
Before the start of a sprint, a sprint planning meeting is held to decide on the requirements that will be included for development -
these are known as the sprint backlog. The team then commits to delivering these within the sprint cycle.
Every day the scrum master runs a short daily scrum meeting. This is to share the status of what’s being developed and
identify any potential issues. Attendees should be able to answer the questions:
•What have you done since the last meeting?
•What will you do between now and the next
meeting?
•Is there anything that will stop you from doing what you
have planned?
Writing Requirements
Requirements are documented in a variety of ways depending on their priority. To start with all requirements are described at a high level, termed an Epic, which describes the theme for particular functionality. Those requirements of medium priority are then be broken down into three to five key features to give sufficient insight to the development team so that they understand where the development might be heading.
The highest priority requirements to be built in the next sprint, are described in far more detail written as user
stories. These are short,
simple descriptions of features told from the
user perspective; As a [user], I want to
[goal] so that [outcome]. Software tools such as Pivital can be used to capture/prioritise/manage the stories, and can be accessed from PC, tablet, and mobile.
