Agile development: a PM’s perspective Sue Clarke

Introduction My first exposure to Agile PM Lifecycle Development methodology Introduction and key principles Must haves Advantages Lessons learnt Summary Q&A Change Name, Department in the View menu, Header and Footer Date

PM lifecycle Strategy/ideas generation Product development Project management Benefits management Delivery life cycle Development options Date

Background to Agile XP In early 1990s Kent Beck was thinking about an “agile approach” to software development that made every thing seem simple and more efficient XP is successful because it stresses customer satisfaction. It is designed to deliver the software to customer needs, when it is needed. XP empowers developers to confidently respond to changing customer requirements, even late in the life cycle XP emphasises team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software

Principles Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Behaviours needed to follow XP Communication Simplicity Feedback Courage

Key practices User stories Planning games Iterations/time-boxing Test criteria Planning games Iterations/time-boxing Estimation and tracking Re-factoring Maximise up-front benefits ”

Iteration 1 standup What was achieved? What is happening next? What’s getting in the way? Tracking? Planning game 2 Re-estimate?

Agile development Change is expected and time is considered more important than functionality i.e. the customer must make trade offs.    The Customer directs development in timebox Big changes outside a timebox Customer can add/remove/change any requirement Requirement documented on cards as user stories Developers re-estimate; factoring . Change Name, Department in the View menu, Header and Footer Date

Agile development Peer review and pair programming – multi-skilling Quality goals set as part of requirement Unit tests designed as part of requirement statement Parallel UAT while still developing Fit iterations and releases into rolling project plan Change Name, Department in the View menu, Header and Footer Date

Agile development methodology Agile methodology – XP subset Kent Beck and Smalltalk roots Adaptive not predictive approach Strong emphasis on testing Project life cycle surrounding development Change Name, Department in the View menu, Header and Footer Date

The PM basics Key user Weekly meeting for all other users Suppliers on site Co-location of team members Daily standups Staged releases (TTL) Go/no go criteria Change Name, Department in the View menu, Header and Footer Date

Must haves Selecting the customer is key – empowered, knowledgeable and a good communicator Clear benefits identified up front Change to achieve benefits clearly prioritised/understood Change Name, Department in the View menu, Header and Footer Date

Advantages Gets round the world moving on while waterfall method used; adapts to environment User buy in to solution is total Documentation kept lean and mean Supports step change; user training and education in small chunks Reduces risk Change Name, Department in the View menu, Header and Footer Date

Lessons learnt Culture Clear Vision Customer experience People and energy JFDI Personal not e-mail Knowledge not position Clear Vision Focus on the why, not the how Change Name, Department in the View menu, Header and Footer Date

Lessons learnt Iterative TTL Key user choice Hard to sell Heavy on user commitment but they love it Key user choice Watch out for pulling fast ones Hard to sell Not just for software (Siemens) Change Name, Department in the View menu, Header and Footer Date

Summary Great for rapid results May not suit regulatory change Won’t fit all cultures Agile PM methodology as well Empowerment of people Focus on benefits not systems A softer way........ Any questions? Change Name, Department in the View menu, Header and Footer Date