Agile philosophy: A summary
Tags: dev, canonical
Published: 2022-08-09 21:12:48

_Originally published at [robinwinslow.uk/agile-philosophy](https://robinwinslow.uk/agile-philosophy)_

Following are some guidelines about Agile philosophy that I wrote for my team back in September 2012.

I also wrote a popular [StackExchange answer about Agile project planning](http://programmers.stackexchange.com/questions/166570/programming-vs-planning/166591#166591) which you might fine useful if you're thinking about implementing Agile.

---

[Agile software development](http://en.wikipedia.org/wiki/Agile_web_development) is a philosophy for managing software projects and teams. It has similarities to [lean manufacturing](http://en.wikipedia.org/wiki/Lean_manufacturing) principles for "eliminating waste".

The philosophy centers around [the agile manifesto](http://en.wikipedia.org/wiki/Agile_software_development#Agile_Manifesto):

> We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
>
> - Individuals and interactions over Processes and tools
> - Working software over Comprehensive documentation
> - Customer collaboration over Contract negotiation
> - Responding to change over Following a plan
>
> That is, while there is value in the items on the right, we value the items on the left more.

Of the various [software development methodologies](http://en.wikipedia.org/wiki/Software_development_methodology) out there, [Scrum](http://en.wikipedia.org/wiki/Scrum_(development)) and [Extreme programming](http://en.wikipedia.org/wiki/Extreme_Programming) particularly try to follow agile software development principles.

[Lean software development](http://en.wikipedia.org/wiki/Lean_software_development) is also rapidly gaining support within the agile community.

## Agile practices and principles

Without choosing to follow any one defined methodology for project management, here are some common practices that could be adopted by an agile team:

- Maintain a [prioritised backlog](http://guide.agilealliance.org/guide/backlog.html) of work with a single backlog manager.
- Have a team [whiteboard](http://www.allaboutagile.com/the-power-of-a-whiteboard/) with sticky notes for keeping track of your tasks and blockers - it really helps to have visibility of the work taking place.
- Break down work into [manageable chunks](http://pivotallabs.com/epic-sharding/) - each less than a day's work.
- Structure your stories so they they [depend on each other as little as possible](http://itsadeliverything.com/user-story-dependencies-are-more-apparent-than-real).
- Try to use [relative sizing](http://guide.agilealliance.org/guide/relative.html) to size up work, rather than actual concrete amounts of time. [Here's why](https://www.youtube.com/watch?v=90Xx8QVnXRc).
- Have a daily [stand-up meeting](http://en.wikipedia.org/wiki/Stand-up_meeting) including as many stake-holders as possible so everyone knows what's going on and how things are progressing.
- Try to produce the [minimum viable product](http://en.wikipedia.org/wiki/Minimum_viable_product) (this principle is linked to [release early release often](http://en.wikipedia.org/wiki/Release_early,_release_often) and [iterative development](http://en.wikipedia.org/wiki/Iterative_and_incremental_development)).
- [Fixed timescales, variable requirements](http://www.allaboutagile.com/agile-principle-3-time-waits-for-no-man/) - have fixed production deadlines and structure work such that chunks can be dropped from the iteration if they're not ready.
- Measure the team's [velocity](http://en.wikipedia.org/wiki/Velocity_(software_development)) and use it to estimate work.
- Use [pair-programming](http://en.wikipedia.org/wiki/Pair_programming) for knowledge-sharing and for working through [impediments](http://www.leanagiletraining.com/scrum/what-are-impediments/).