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 I want to so that “ 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