Posts Tagged ‘Incremental’

Agile

There are two main definitions of ‘Agile’ which people tend to refer to when:

  1. Delivering software iteratively and in increments rather than holding all of the software back delivering one big release somewhere down the line
  2. The business responds to change / demands rather than sticking to a long term strategy just because it was previously agreed

Both definitions of the term are valid, but in software development the first use is most common whereas everyone else in a business typically refer to the second.

Scrum is the most common Agile framework where typically the expectation is that you release code / software to live every fortnight / within the Sprint whether it uses a feature switch or setting the code live to customers. This has many benefits such as:

  1. Realising value sooner – value being delivered within the sprint off the back of the development work the team committed to during sprint planning
  2. Predictability of future software releases
  3. General team organisation – all work in the sprint will be fully done so you won’t have to deal with the previous sprints pre-production testing or release in the following fresh sprint, making it less messy and reducing the impact of context switching (Dev Ops culture – continuous delivery)
  4. Responding to customer feedback quicker adjusting scope for future iterations off the back of it
  5. Large chunks of development work won’t be sitting on the shelf collecting dust or thrown away without any customer / end user receiving any of the goods
  6. Ability to deliver the highest ROI pieces of work, so rather than having to wait until a feature is gold plated, you may find after the 3rd iteration that the majority of value has been delivered, therefore it might be higher priority to start work on another feature than fully completing the existing one
  7. Self organising, cross functional teams including UX and design

Only once you’ve ticked off all of the above can you say that you develop software in an Agile way.

The business use of the term Agile is more focused on the ability to adapt to change quickly and shuffle around priorities to meet changing core objectives within a reasonable time frame, rather than continuing to work on something which will generate half the ROI than another feature or a feature which is no longer needed. Naturally you need to include any context switching cost when changing in flight priorities and it’s recommended not to change high level priorities frequently because you may find yourself delivering very little over time and instead just causing lots of admin and frustrated developers.

Being Agile is certainly not easy to achieve, but having the ambition and desire to start delivering value in an Agile way is something which is definitely worth any necessary process or infrastructure change in order for the benefits of Agile to be unlocked.