Agile development

By Sam Chamberlain

First a bit of history..

Waterfall development and the V model

Waterfall the V model

• In the beginning there was no process• Then waterfall is / was a very heavily used

software development lifecycle (SDLC)• V model is an enhancement on the waterfall

method with corresponding testing materials being prepared at each stage

• Traditional project management is similar. For example PRINCE 2, MS Project, Gant charts etc.

V model characteristics

• Try and decide requirements at the beginning• Budget and time also fixed• Lots of detailed, up-front specification and

modelling (UML for example)• What usually happens is requirements change

somewhat and then time and budgets slip as well• Disconnect between business and development• Testing and quality often an afterthought

Introducing Agile

• Iterative and incremental • Fixed, time-boxing but then changing, prioritised

requirements• Customer focussed • The Agile manifesto – Individuals and interactions over processes and tools– Working software over comprehensive documentation– Customer collaboration over contract negotiation– Responding to change over following a plan

More from the Agile Manifesto• Customer satisfaction by rapid delivery of useful software• Welcome changing requirements, even late in development• Working software is delivered frequently (weeks rather than months)• Working software is the principal measure of progress• Sustainable development, able to maintain a constant pace• Close, daily co-operation between business people and developers• Face-to-face conversation is the best form of communication (co-

location)• Projects are built around motivated individuals, who should be trusted• Continuous attention to technical excellence and good design• Simplicity- The art of maximizing the amount of work not done - is

essential• Self-organizing teams• Regular adaptation to changing circumstances

Agile and Agile Scrum

• Scrum is a popular Agile methodology• Different to XP - eXtreme Programming or Unified

Process, Lean etc.• But methodologies can be mixed• Characteristics of scrum– Sprints– Product and sprint backlog– Stand-up – User stories

Agile scrum - lifecycle

Scrum roles

• Product owner– Responsible for Product Backlog– Interface with business, stakeholders and customers– Removes product obstructions

• Scrum master– Facilitator for the scrum team – Enforces rules– Removes team obstructions

• Development team– Programmers– Testers

Scrum lifecycle• Daily stand-up / scrum – “what have I done, what am I

doing next, are there obstructions”• Backlog grooming with Product Owner• Sprint planning and “planning poker ”mainly with

Development team• Development and testing• No new stories in the sprint• “Done, done”• Product release – working software and communication

with stakeholders• Sprint retrospective

Agile – board

Sample – burn-down chart

User stories and their use• "As a <user type> I want to <do some action> so that

<desired result>“• Small piece of functionality needed by a user– Stack rank – i.e. priority– Story points – important: measure of complexity only – Associated tasks – with time estimates

• Includes detailed “acceptance criteria”• Should be at least one test for each acceptance criteria

item• “Done, done” means a story has been closed – i.e. all

tests passed successfully

Agile bugs• Bugs found in the iteration should be fixed in the

iteration, otherwise the relevant story should be removed from the iteration. Planning needs to make time for this

• Other bugs or customer bugs are placed in the backlog and put into iterations during planning

• Bugs need to be reproducible and fully analysed before they are added to the backlog

• Continuous integration and automated testing as well as experienced scrum will mean less bugs. A well working scrum often has no open bugs

Successful Agile• Constant improvement of process • Deliver around the same amount of story points each iteration• Even burn-down rate• Contents of iteration planning match what is released at the

end of each iteration• Confident stakeholders – “if we don’t get it this iteration, we’ll

get it in two weeks” • Constant refactoring• No or very few open bugs• Regular “cool-down” and refactoring iterations

Other aspects of Agile

• Product roadmap and vision• Release notes and other documentation • Self organising teams• No managers, aside from line-managers – Scrum Master tries to enforce rules, remove impediments– Product Owner manages the product backlog and priorities,

but has no control over what the scrum actually does • Pair programming – used allot in XP• Scrum / Agile works very well with SAAS

Continuous integration

• Technical: Scrum / developer responsibility • Code repository and daily builds• Constant check-ins• Tests run frequently• Automated testing – build up a regression test suit

(code) that can be run any time, quickly• Separate Dev, testing, staging and live systems• Can help to have a tool to manage everything from the

scrum, to the code and check-ins, to the test suit, to reporting – for example MS TFS

Implementing Agile for a Company• Asses suitability of Agile and appropriate parts• Form team and define roles• Good to have experienced Scrum Master• Need dedicated tester(s)• Need Product Owner• Decide on tool(s)• Product Road map• Define and start to prioritise and groom user stories• Start scrum cycles• Move towards continuous integration and automated testing

Sam Chamberlain – relevant skills

• Plan and implement high level Agile processes• Guidance on Agile and Agile principles• Product ownership• Product road map and product release• Business and systems analysis• Extensive technical knowledge • Testing and training• Supplier shortlisting, selection and management • Recruitment

Questions?

Thank you