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 which you might fine useful if you’re thinking about implementing Agile.
Agile software development is a philosophy for managing software projects and teams. It has similarities to lean manufacturing principles for “eliminating waste”.
The philosophy centers around the 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 out there, Scrum and Extreme programming particularly try to follow agile software development principles.
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 of work with a single backlog manager.
- Have a team 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 - each less than a day’s work.
- Structure your stories so they they depend on each other as little as possible.
- Try to use relative sizing to size up work, rather than actual concrete amounts of time. Here’s why.
- Have a daily 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 (this principle is linked to release early release often and iterative development).
- Fixed timescales, variable requirements - 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 and use it to estimate work.
- Use pair-programming for knowledge-sharing and for working through impediments.