Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile an explanation by sedulous business solutions


Published on

Agile Methodology explained simply, for those unfamiliar. Great to change organisations from waterfall to agile ways of working. Step by Step. Agile Project Delivery simplified. Stakeholders will understand clearly what their role is in implementation. Answers common questions, what is a Scrum Master etc

  • Be the first to comment

Agile an explanation by sedulous business solutions

  1. 1. Agile Project Delivery
  2. 2. Contents  What is Agile?  The Agile approach  Agile Roles  Delivery Process  In More Detail
  3. 3. What is Agile? • A description • Principles • Misconceptions • Agile v Waterfall • Why choose Agile • Time Cost and Quality
  4. 4. A description  Agile systems development is a group of systems development methods based on ‘iterative’ and ‘incremental’ delivery of small chunks of work, where ‘features’ evolve through collaboration between IT and business teams.  It promotes adaptive planning, evolutionary development and delivery, a ‘time-boxed’ iterative approach, and encourages rapid and flexible responses to business change.  It is a conceptual framework that promotes foreseen small manageable stages throughout the delivery cycle.
  5. 5. "We are uncovering better ways of developing systems to support business change, 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." Agile Principles (manifesto)
  6. 6. Agile misconceptions.. Agile doesn’t work for fixed deadline projects – Quite the contrary, it works best in fixed deadline projects, as this will focus collaboration. Agile delivery only requires new tools – To be successful, Agile delivery requires cultural, process, and tool changes to be made Agile means no documentation – Wrong!.. Agile promotes ‘smart documentation’ used for collaboration and delivering small efficiencies often. Its all about working smarter, not cutting corners Agile means no planning – Some upfront planning is required for Agile projects and should include details such as development principles, an estimate of the work and tasks involved, priorities, and overall budget to act as a guide for decisions during delivery. Agile “out of the box” is good for every project – No.. When applying Agile to large projects and distributed delivery teams or very large teams, some modifications and care need to be taken to provide for their unique needs and requirements. Combinations of methodology can be used to support governance structures.
  7. 7. Agile v Waterfall.. A comparison Deploy Document Plan Build Test Change Cycle Project Lifecycle Waterfall >
  8. 8. Agile v Waterfall.. A comparison ** Documentation becomes part of the build process Project Lifecycle Plan Build Test Plan Build Test Plan Build Test Plan Build Test Deploy Deploy Deploy Deploy Change Cycle Change Cycle Change Cycle Change Cycle Agile >
  9. 9. Why choose Agile? ROI ROI
  10. 10. Time, Quality and Cost Features fixed therefore: Time Quality and cost vary. Time, Quality and cost fixed: Controlled by varying the features, and delivering ‘High Value’ features first
  11. 11. The Agile approach P3O
  12. 12. Product Delivery (Scrum) Governance Practices Combining methodologies (Atern) Programme Delivery - Outcomes (MSP) Project Delivery - Outputs (PRINCE2) Project Sprint Sprint Sprint Sprint Sprint End Stage Assessment Tranche Review Sprint Retrospective Iteration (Stage) Product Feature System Features Iteration Iteration Iteration Portfolio Delivery – Delivering the business Strategy Strategic Capability
  13. 13. Agile Roles • Scrum Roles • Who is the Scrum Master • Agile relationships
  14. 14.  Scrum Master – Responsible for coaching and guiding the team, creating a trustful and inclusive environment, facilitating team meetings and negotiations with the product owner and removing team and organisational impediments. They keep the process moving forward ensuring that the values and principals of scrum along with its framework are followed. They socialise scrum and agile to the wider organisation.  Product Owner – Is the final authority on the requirements for the product. Responsible for the product vision and improving return on investment. They manage the end user and stake holder expectations, prioritizing the product backlog, release planning and providing clear and testable requirements to the team. They collaborate with the team, end users and stake holders ensuring that the goals are met and they accept the software at the end of each sprint.  The Team – The team are cross-functional, autonomous and self organising. They are responsible for estimating the size of requirements driving from a tactical perspective making their own design and implementation decisions. They track the progress of their own work with the guidance of the scrum master and the team commit to delivering increments of software being accountable to the product owner for delivering as promised. Scrum Roles
  15. 15. ‘Scrum’ term that refers to a collaborative agile team management structure used during agile delivery. Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The ScrumMaster's role is more that of coach and facilitator, a role that sits between the project and the customer. The ScrumMaster doesn't manage the team that produces the work; instead, he/she supports the product owner, coaches the team, and makes sure that Scrum processes are adhered to. The ScrumMaster is responsible for the Scrum process, its correct and continuous implementation, and the maximization of its benefits Who is the Scrum Master? SM?
  16. 16. Agile Relationships The organisation Stakeholders/ SME’s Scrum Master The Team Users Product Owner
  17. 17. Delivery Process • Core Concepts • Identifying the Requirements (Product Backlog) • Epic Stories • User Stories • Prioritising the Backlog • KanBan • Delivery Cycle
  18. 18.  ‘Product Backlog’ – A list of items (requirements) that deliver capability to the business. These are product based i.e. ‘Managing clients’, ‘Creating legal cases’.  ‘Sprint’ – Length of time agreed to deliver Items in the backlog to the business. Usually 1-2 weeks.  ‘Daily Stand-up’ - Daily meeting with all team members (Business/IT) to discuss current tasks. Usually 15-20 Mins. Core Concepts
  19. 19.  ‘Epic Story’ – Narrative that describes an operational goal needed to satisfy a strategic objective i.e. “As an education lawyer I want to be able to create, amend, delete and search for clients so that I can create and education legal case, by attaching a clients information to a legal matter”  ‘User Story’ – Detailed breakdown of an Epic Story, based upon a role, a task and a reason i.e. “As an education administrator, I want to be able to search for a client, so that if they already exist I will not be able to create a duplicate client” Core Concepts
  20. 20.  Identify Key project success factors.  Identify the processes in scope.  De-compose the processes into mapped tasks.  Logically group those tasks into Epic Stories.  Add the Epic Stories to the Product backlog.  Prioritise the Epic Stories using MoSCoW  De-compose the Epic Stories into User Stories Identifying the Requirements (The Product Backlog)
  21. 21. Identify the Processes
  22. 22. Define Epic Stories ES : Assess Client ES : Money Laundering ES : Resolve Conflict ES : Risk Assessment
  23. 23.  Name of the story.. NOT a number.  Description and acceptance criteria (BDD)  Define any ‘Business’ rules i.e. Client Number format Break Epic Stories into User Stories “As a ‘Role’, I want to be able to, So that I can” “Given a Condition, When I do this, Then It should” TaskRole Reason (Benefit) EventInitial Context Outcome
  24. 24. User Stories example… • User Story – :Adding a Client email address “As a User I want to add a client email address, so that I can automatically email the client” “Given the Client has a valid email address, when I click the email address, then my default email client should open and their email address should be populated in the recipient field”
  25. 25. User Story Register ES: Assess Client : (Epic User Story) Story Name As a I would like to… So that… “As a CRM user, I want to be able to assess whether a client has a conflict so that I can pass them to a manager if necessary for resolution” US: Client type Fee earner Establish the correct client type I can assess the client in the correct manner US: Data Level Fee earner Collect the correct level of data I can proceed to a conflict check US: Check Data Fee earner Check the collected data against current data I can establish if there is a need for a conflict check US: Send Data Fee earner Send the data to the correct manager They can resolve the conflict
  26. 26. Prioritising the Backlog & Sprint Allocation User story Description Priority (MOSCOW) Effort (days) Sprint No. Owner ES: Assess Client Assess Client M 5 1 ES: Money Laundering Money Laundering M 5 1 ES: Resolve Conflict Resolve Conflict S 7 2 ES: Risk Assessment Risk Assessment S 2 2 ES: Cancel Client Cancel Client S 1 2 • Size the stories • Group User Stories into same size Sprints • Deliver on Prioritisation
  27. 27.  Developed in the 1940’s by Toyota.. To align inventory levels by consumption – “Pull’ environment.. Rate of demand controls production, and task based.  Define the tasks needed to deliver the user stories KanBan Sprint 1: Assess Client To Do In Progress Completed User Story US : Client Type US : Data Level Develop Client Type Test Client Type Develop Data Level Test Data Level Import client data Get Type List
  28. 28. Daily Scrum The Delivery Lifecycle Sprint 1 ES: Assess Client ES: Money Laundering Sprint 2 ES: Resolve Conflict ES: Risk Assessment ES: Cancel Client Sprint 1 Backlog ES: Assess Client ES: Money Laundering Sprint Planning and Review Build the KanBan Sprint 2 – 4 Weeks Completed Assess Client Money Laundering Completed Assess Client Money Laundering Resolve Conflict Risk Assessment Cancel Client Identify Product Backlog Kan Ban Build / Test
  29. 29. In More Detail..
  30. 30. In More Detail • CDLC (Change Delivery Lifecycle) • ITIL Structured • Service Strategy • Service Design • Service Transition
  31. 31. The CDLC (Change Delivery Lifecycle) Transition Methodology Agile DeliveryJADJRPBusiness Architecture Product DeliveryProduct Definition RFC Business case PID Product Backlog (Epic Stories) Product Backlog (User Stories) Define Sprint Backlogs JRP – Joint Requirements Planning JAD – Joint Application Development
  32. 32. Team Service Strategy
  33. 33. Service Design Team User Service Design
  34. 34. Team User Service Transition
  35. 35. 4. ‘Lean’ to ‘Agile’ delivery ‘BPM’ ‘Lean’ ‘BAM’ ‘Process Models’ User Stories Product Backlog Activity Diagrams Sprints Sprint Backlog Build and Test A Product Business/BRM Business and BA Business, BA and Team Business
  36. 36. 5. Agile values to take away… ‘Agile’ is also a group of processes - ensure ‘Lean’ is also applied to Agile. • Time boxed sprints - “Divide and conquer” • Collaboration – “Lets Keep talking” • Deliver rapidly – “Small things often” • Flexible – “Adapt to your environment” • Manage Change – “Adapt to the business need” • Joint Ownership – “Everyone has their part to play” • Empowerment – “Everyone is a decision maker” “Everyone together from the start !”