More Related Content
Similar to An Introduction to Agile
More from DavidMcLachlan1
An Introduction to Agile
- 1.
- 2. Overview • The differenttypes of project environments • The different types of project lifecycles • The four Agile values • The twelve Agile clarifying principles • Core Agile practices • Agile and Lean frameworks • Delivering in an Agile environment
- 3. Life Cycle Selection Wheredoes Agile fit in Product and Project Management?
- 4. Life Cycle Selection Coincideswith APG 3.1 Projects come in all shapes and sizes, and there are a variety of ways to manage them. Different organisational structures Different lifecycles Different management styles Different sizes Different customer needs Different products or outputs The list goes on…
- 5. An Introduction toAgile Coincides with APG 3.1 There are different types of projects You might have co-located teams or dispersed teams. You might be governed by a supportive, controlling or directive PMO, or a functional manager. Your sponsor or customer may want daily reports, or weekly reports. You may have more than one customer group receiving the benefit of the project. The project may be technically simple, or complex. The project may have easily definable work, or high uncertainty work.
- 6. An Introduction toAgile Coincides with APG 2.1 Definable Work Versus High Uncertainty Work Project work ranges from definable work to high-uncertainty work. • Definable: Clear procedures, similar to past projects • e.g. Production of a car, appliance or home after the design is complete • High-Uncertainty: High rates of changes, complexity and risk • e.g. System or problem solving engineers, product designers, doctors, lawyers, teachers.
- 7. An Introduction toAgile Coincides with APG 2.1 Definable Work Versus High Uncertainty WorkHighUncertaintyLowUncertainty Requirements Technical Challenges Chaos Simple High UncertaintyLow Uncertainty Complicated Complex Linear approaches work well here Adaptive approaches work well here Fundamentally risky
- 8. Life Cycle Selection Coincideswith APG 3.1 HighLow FrequencyofDelivery Degree of Change HighLow Predictive Iterative Incremental Agile No life cycle can be perfect for all projects. Instead, each project finds a place on the continuum that provides an optimum balance.
- 9. Life Cycle Selection Coincideswith APG 3.1 Predictive life cycle The traditional “waterfall” approach, with the bulk of planning done up front, then executing in a single, sequential process. Iterative life cycle An approach that allows feedback for unfinished work to improve and modify that work. Incremental life cycle An approach that provides finished deliverables that the customer may be able to use immediately. Agile life cycle An approach that is both iterative and incremental, to refine work items and deliver frequently
- 10. Characteristics of LifeCycles
- 11. Life Cycle Selection Coincideswith APG 3.1 Approach Requirements Activities Delivery Goal Predictive Fixed Performed once for the entire project Single delivery Manage cost Iterative Dynamic Repeated until correct Single delivery Correctness of solution Incremental Dynamic Performed once for a given increment Frequent smaller deliveries Speed Agile Dynamic Repeated until correct Frequent small deliveries Customer value via frequent deliveries and feedback Every project has characteristics around requirements, delivery, change and goals. Understanding the different types of life cycle, you can choose the right one for the circumstances of your project.
- 12. Characteristics of LifeCycles Coincides with APG 3.1 Predictive Life Cycles Analyse Design Build Test Deliver • Also known as “Waterfall” life cycles, predictive life cycles take advantage of high certainty around requirements, a stable team, and low risk. • As a result, project activities often execute in a straight forward, serial manner. • As the team progresses through the detailed plan, they monitor and control changes that might affect the Scope, Schedule, or Budget (cost). • Projects typically do not deliver business value until the end of the project.
- 13. Characteristics of LifeCycles Coincides with APG 3.1 Iterative Life Cycles • Iterative life cycles improve the product or result through successive prototypes or proofs of concept. Each new prototype yields new stakeholder feedback and team insights. • Teams may use time-boxing on a given iteration of two to four weeks to build, gather feedback, then put that feedback into the next iteration. • Useful when complexity is high, or scope is subject to change. • Iterative life cycles take longer as they are optimised for learning, rather than speed of delivery. Analyse Analyse, Design Build, Test Deliver Prototype Refine
- 14. Characteristics of LifeCycles Coincides with APG 3.1 Incremental Life Cycles Analyse Design Build Test Deliver Analyse Design Build Test Deliver Analyse Design Build Test Deliver • When businesses or initiatives cannot afford to wait for everything to be completed. • In this situation the customer, business, or sponsor are willing to receive a subset of the overall solution delivered in frequent small releases. • You could provide a single feature at a time • Increments are time-boxed in iterative methods, or pulled in flow based methods like Kanban.
- 15. Characteristics of LifeCycles Coincides with APG 3.1 Agile Life Cycles Requirements Analyse Design Build Test Requirements Analyse Design Build Test Requirements Analyse Design Build Test • In an Agile environment, the team expects requirements to change • Iterative and Incremental approaches work together – to provide feedback for planning the next iteration, and uncovering hidden or misunderstood requirements (using increments) • For Kanban, or Flow based Agile, it is iterated for the number of features in the Work in Progress (WIP) limit (on the board). The team pulls features from the backlog column on the Kanban board based on their capacity.
- 16. Characteristics of LifeCycles Coincides with APG 3.1 Agile Life Cycles Requirements Analyse Design Build Test Requirements Analyse Design Build Test Requirements Analyse Design Build Test • Customer satisfaction increases with early and continuous delivery of value • This incremental, functional deliverable that provides value is the primary measure of progress.
- 17. An Introduction toAgile Coincides with APG 2.2 Agile Approach to Constraints Scope Time Cost Quality Scope Time Cost Quality Fixed Variable Waterfall Agile
- 18. Characteristics of LifeCycles Coincides with APG 3.1 Hybrid Life Cycles • Projects often combine elements of different life cycles in order to achieve their goals. • A combination of predictive, iterative, incremental and agile approaches is a hybrid approach. You might have: • Largely agile, with some predictive • Where you are integrating an external component developed by a different vendor • A single iteration might be required after their component is delivered • Predominantly predictive, with some agile components • Where you are delivering a straight forward project (a shed or patio), but trialling a new roofing material. • A combined predictive and agile approach • A serial or linear project, where tasks are tracked using Kanban and daily scrums are used for updating work.
- 19. Characteristics of LifeCycles Coincides with APG 3.1 Project Factors That Influence Tailoring Project Factor Tailoring Options Demand pattern: Steady or sporadic Many teams find that using a cadence (like a regular time-box) helps them demo, retrospect and take in new work. In addition, teams can use flow-based agile with a cadence to bring flexibility in acceptance of their work. Rate of process improvement required by the level of team experience Retrospect more often and select improvements The flow of work is often interrupted by various delays or impediments Consider making work visible using Kanban boards and experimenting with limits for the various area of the work process in order to improve flow. The quality of product increments is poor Consider using the various test-driven-development practices. This mistake proofing discipline makes it difficult for defects to remain undetected. More than one team is needed to build a product To scale from one to several agile teams with minimal disruption, first learn about agile program management or formal scaling frameworks. Then craft an approach that fits the project context. The project team members are inexperienced in the use of agile approaches Consider starting by training the team members in the fundamentals of the agile mindset and principles and an overview of the approaches. If the team decides to use a specific approach like Scrum or Kanban, provide a workshop on that approach so they can learn how to use it.
- 20. An Introduction toAgile Coincides with APG 2.2 The Agile Manifesto and Mindset In 2001, a group of individuals, representing the most widely used lightweight software development methodologies, agreed on a common set of values and principles which became known as the Agile Manifesto. The Agile Manifesto contains four statements of values:
- 21. An Introduction toAgile Coincides with APG 2.2 The Agile Manifesto and Mindset The Four Values Individuals and interactions over Processes and Tools Working software over Comprehensive documentation Customer collaboration over Contract Negotiation Responding to change over Following a plan The Agile Manifesto argues that although the concepts on the right have value, those on the left have greater value.
- 22.
- 23. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 24. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- 25. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- 26. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 4. Business people and developer must work together daily throughout the project.
- 27. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- 28. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 6. The most efficient and effective method of conveying information to and within a development team is face to face conversation.
- 29. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 7. Working software is the primary measure of progress.
- 30. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- 31. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 9. Continuous attention to technical excellence and good design enhances quality.
- 32. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 10. Simplicity – the art of maximising the amount of work not done – is essential.
- 33. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 11. The best architectures, requirements, and designs emerge from self organising teams.
- 34. An Introduction toAgile Coincides with APG 2.2 The Twelve Clarifying Principles 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
- 35.
- 36. Core Agile Practices Coincideswith APG 4.0 • Whole team approach • Early and Frequent Feedback • Daily stand-ups • Retrospectives • Release and Iteration Planning • Collaborative User Story Creation • Demonstrations / Reviews • Continuous Integration • Servant Leadership
- 37.
- 38. Coincides with APG4.3 Whole Team Approach • The whole-team approach means involving everyone with the knowledge and skills necessary to ensure project success. • The team should be relatively small (successful teams have been observed with as few as three people and as many as nine). • Ideally, the whole team shares the same workspace (as co-location strongly facilitates communication and interaction) • Teams are often 100% dedicated to the delivery, because when switching or multitasking people make more mistakes and experience between 20% and 40% loss of productivity. Core Agile Practices
- 39. Coincides with APG4.3 Whole Team Approach • Agile teams are cross-functional, “generalising specialists”, or “T- shaped” people, with one focus specialty and then a breadth of experience across multiple skills. • The team includes representatives for the Product Owner, the Team Facilitator, and Cross Functional team members. Core Agile Practices
- 40. Coincides with APG4.3 Whole Team Approach • To overcome organisational silos, work with the various managers of team members you need and have them dedicate the necessary individuals to the cross-functional team. • This creates the team synergy you need, and allows the organisation to see how leveraging its people will optimise the product being built. Core Agile Practices
- 41. Coincides with APG4.3 Whole Team - Cross Functional Team Member Role Description Cross Functional Team Member Cross functional teams consist of team members with all the skills necessary to produce a working product. In software development, cross functional teams are comprised of designers, developers, testers, and any other required roles. These teams deliver small, releasable products on a regular basis. The are critical because they can deliver finished work in the shortest possible time, with higher quality, without external dependencies. Core Agile Practices
- 42. Coincides with APG4.3 Whole Team – Product Owner Role Description Product Owner The Product Owner represents the customer, and generates, maintains, and prioritizes the product backlog to ensure the highest business value without creating waste. This person is not the team lead. They may work with stakeholders, customers and the teams to define the product direction, and rank the work based on its business value. Typically, product owners have a business background and bring deep subject matter expertise to the decisions. Core Agile Practices
- 43. Coincides with APG4.3 Whole Team – Team Facilitator Role Description Team Facilitator The Team Facilitator, or servant leader, can be called a project manager, scrum master, project team lead, team coach, or team facilitator. The whole team approach is supported through the daily stand-up meetings, facilitated by this servant leader role. All agile teams need servant leadership on the team , and team members need to build their own servant leadership skills of facilitation, coaching, and removing blockers. Core Agile Practices
- 44. Coincides with APG4.3 Whole Team Approach • The use of a whole-team approach to product development is one of the main benefits of Agile development. Its benefits include: • Enhancing communication and collaboration within the team • Enabling the various skill sets within the team to be leveraged to the benefit of the project • Making quality everyone’s responsibility • The whole team is responsible for quality in Agile projects. Core Agile Practices
- 45.
- 46. Core Agile Practices Coincideswith APG 2.2 Early and Frequent Feedback • Agile projects have short iterations enabling the project team to receive early and continuous feedback on product quality throughout the development lifecycle. • By getting frequent customer feedback as the project progresses, Agile teams can incorporate most new changes into the product, and the development process.
- 47. Core Agile Practices Coincideswith APG 2.2 Early and Frequent Feedback • The benefits of early and frequent feedback include: • Avoiding requirements misunderstandings, which may not have been detected until later in the development cycle when they are more expensive to fix. • Clarifying customer feature requests, making them available for customer use early. This way, the product better reflects what the customer wants. • Discovering (via continuous integration), isolating, and resolving quality problems early. Providing information to the Agile team regarding its productivity and ability to deliver. • Promoting consistent project momentum.
- 48.
- 49. Core Agile Practices Coincideswith APG 5.2 Daily Standups Teams use standups to micro-commit to each other, uncover and remove blockers, and ensure work flows smoothly through the team. • Timeboxed to 15 minutes • Walk through the Kanban or task board • Team facilitator / Scrum master or anyone in the team can facilitate • Ideally in person, but can be virtual
- 50. Core Agile Practices Coincideswith APG 5.2 Daily Stand-ups In iteration-based agile, everyone answers the following questions in a round- robin fashion: • What did I complete since the last stand-up? • What am I planning to complete between now and next stand-up? • What are my impediments (or risks, blockers, problems)? If problems do arise, take them “offline” – put them in an issue parking lot and don’t try and solve them during the stand-up.
- 51.
- 52. Core Agile Practices Coincideswith APG 5.2 Retrospectives In Agile development, a retrospective is a meeting (often held at the end of an iteration of around two weeks) to discuss what was successful, what could be improved, and how to incorporate the improvements and retain the successes in future iterations. • What worked well? • What didn’t work well? • What have I learned? • What still puzzles me?
- 53. Core Agile Practices Coincideswith APG 5.2 It meets Agile principle 12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” The Retrospective is seen as one of the most important practices because it helps the team learn about and improve their process over time.
- 54. Core Agile Practices Coincideswith APG 5.2 You can also hold Retrospectives at any other time, such as: • When the team completes or ships something new • When more than a few weeks have passed since the previous retrospective • When the team appears to be stuck and completed work is not flowing • When the team reaches any other milestone
- 55.
- 56. Core Agile Practices Coincideswith APG 5.2 Release and Iteration Planning For Agile lifecycles, two kinds of planning occur, release planning and iteration planning. In release planning, business representatives establish and prioritize the user stories for the release, in collaboration with the team, refining larger user stories into a collection of smaller stories.
- 57. Release and IterationPlanning Backlog Preparation The Backlog is the ordered list of all the work, presented in “story” form, for a team. The facilitator encourages the team to work in triads of a developer, tester, and product owner/business analyst to discuss, write, and then place enough stories into an iteration, and enough features for a first release. Core Agile Practices Coincides with APG 5.2
- 58. Release and IterationPlanning In iteration planning, the team selects user stories from the prioritized release backlog, elaborates the user stories, performs a risk analysis for the user stories, and estimates the work needed for each user story. The number of stories selected is based on established team velocity and the estimated size of the selected user stories. “Velocity” is the rate a team can complete work (e.g. 16 medium sized cards per iteration) Core Agile Practices Coincides with APG 5.2
- 59.
- 60. Collaborative User StoryCreation Poor specifications are often a major reason for project failure. In Agile development, user stories are written with the developers, testers, and business representatives, with frequent informal reviews to ensure they are right. Core Agile Practices Coincides with APG 5.2
- 61. Collaborative User StoryCreation A user story: • Addresses both functional and non-functional requirements • Includes acceptance criteria for these characteristics, which must be: • Estimable, Small, and Testable • See Behaviour Driven Development (Given, when, then) Core Agile Practices Coincides with APG 5.2
- 62. Collaborative User StoryCreation Three C’s of User Stories: • Card: • The physical media describing a user story. It identifies the requirement, its criticality, expected development and test duration, and the acceptance criteria for that story • Conversation: • Explains how the software will be used, evolving in conversations with the product owner and developers. • “As a” - “I want” - “So that I can” or Given, When, Then. • Confirmation: • The acceptance criteria, discussed in the conversation, are used to confirm that the story is done. Core Agile Practices Coincides with APG 5.2
- 63.
- 64. Core Agile Practices Coincideswith APG 5.2 Demonstrations / Reviews As the team completes features, usually in the form of user stories, the team periodically demonstrates the working product to the customer/business and product owner. Often occurs at the end of an iteration (2 weeks), or when enough features have been completed into a set that is coherent. Team members can get feedback that prevents them from heading in a wrong direction.
- 65. Continuous Integration and otherexecution practices
- 66. Continuous Integration Delivery ofa product increment requires reliable, working, integrated software at the end of every sprint. Continuous integration addresses this challenge by merging all changes made to the software and integrating all changed components regularly, at least once a day. Configuration management, compilation, software build, deployment, and testing are wrapped into a single, automated, repeatable process. Since developers integrate their work constantly, build constantly, and test constantly, defects in code are detected more quickly. Core Agile Practices Coincides with APG 5.2
- 67. Other execution practices •Test at all levels Applying end-to-end testing and unit testing (of an individual story or feature). Agile teams have a preference for automated tests. • Acceptance Test-Driven development (ATDD) Creating end-to-end user acceptance tests by feature, as a team. These tests then feature as reusable “regression tests” for overall functionality, once that feature goes live. • Test-Driven Development and Behaviour Driven Development Writing automated tests before writing the product code helps people mistake-proof the product. For non-software teams, consider prototyping with customers as a test. • Spikes Are timeboxed research or experiments. Useful for estimation, acceptance criteria definition, or learning some critical technical or functional element. Core Agile Practices Coincides with APG 5.2
- 68.
- 69. Servant Leadership Agile approachesemphasise servant leadership as a way to empower teams. Servant leadership is the practice of leading through service to the team, understanding and addressing the needs and development of the team members to enable to highest performance possible. Core Agile Practices Coincides with APG 5.2
- 70. Servant leaders approachproject work in this order: • Purpose Work with the team to define the “why” • People Creating an environment where everyone can succeed • Process Look at the results over the process – if a team delivers value often and reflects on the product and the process, it is agile. Core Agile Practices Coincides with APG 5.2
- 71. Characteristics of aservant leader: • Promoting self-awareness • Listening • Serving those on the team • Helping people grow • Coaching versus controlling • Promoting safety, respect, trust • Promoting the energy and intelligence of others Core Agile Practices Coincides with APG 5.2
- 72. Servant leader responsibilities: •Servant leaders facilitate • Servant leaders remove organisational impediments • Servant leaders pave the way for others’ contribution • Educate stakeholders on agile, mentor the team and encourage career development, help with technical project management activities like quantitative risk analysis, build bridges between external teams or groups. A project manager in an agile environment uses servant leadership. Core Agile Practices Coincides with APG 5.2
- 73.
- 74. Agile and LeanFrameworks Scrum XP Kanban Behaviour Driven Development Agile Unified Process Dynamic Systems Delivery Method A single team management framework “Sign-board” from the Toyota Production System eXtreme Programming a software development method Crystal Scaled Agile Framework Core Methods Many Auxiliary Methods Agile and Lean Frameworks Scrum of Scrums Large Scale Scrum Disciplined Agile Coincides with Agile Practice Guide 3.0 Feature Driven DevelopmentFDD
- 75. Coincides with APG3.0 Scrum Scrum Scrum is a single-team framework for managing product development. The Scrum team consists of a: • Product Owner • The customer - responsible for maximising the value of the product • Development Team • Develops and tests the product. They are cross functional, self organising and have all the roles needed to deliver the product. • Scrum Master • Responsible for ensuring the Scrum processes (i.e. stand-ups and retrospectives), and coaches the team on removing blockers. Agile and Lean Frameworks
- 76. An Introduction toAgile Coincides with APG 3.0 Scrum Events and Artefacts Events Sprint A time-boxed project “iteration” of two to four weeks Sprint Planning At the start of each sprint, the scrum team selects the highest priority items. Daily Scrum A short (15 minute) stand-up meeting to walk through project tasks (often on a Kanban board). Sprint Review The development team gives a demo on the product to the product owner for sign-off (or rework or change) Sprint Retrospective A retrospective at the end of the sprint, to improve the way of work for the next iteration. Artefacts Product Backlog The product owner manages a prioritized list of planned product items which evolves from sprint to sprint. Sprint Backlog The items selected in Sprint Planning for the upcoming sprint. Increments The Increment is all the Product Backlog items completed during a Sprint - a step toward the main vision or goal.
- 77. Coincides with APG3.0 Kanban Kanban translates to “visual sign” or card, in Japanese. Kanban It is a form of Visual management from Lean Manufacturing, for monitoring Work in Progress, and enabling “Pull” and “Flow”. Here is an example of a simplified Kanban board. You could use any columns you like to represent your work. Agile and Lean Frameworks
- 78. Coincides with APG3.0 Kanban Kanban • Pull is where people or teams “pull” work only when they are ready, instead of work or inventory building up. • Flow is where work flows effortlessly through the value chain, with no rework. Kanban does not prescribe “iterations”, but works very well with them (i.e. Scrum). It is helpful when you need: • Increased efficiency • Visibility of each task and ensuring it adds value. • Team member focus • Limited work in progress allows the team to focus on the current work. • Variability in the workload • Reduction of waste • Transparency makes waste visible so it can be removed. Agile and Lean Frameworks
- 79. Coincides with APG3.0 Kanban Kanban • Additionally, the board acts as an information radiator to anyone who sees it, providing up-to-date information on the status of work to the team. Defining Principles Core properties Start with current state Visualise the workflow Agree to pursue incremental, evolutionary change Limit work in progress Respect the current process Manage Flow Lead at all levels Enable “Pull” Make process policies explicit Implement feedback loops Improve collaboratively Agile and Lean Frameworks
- 80. Coincides with APG3.0 eXtreme Programming eXtreme Programming XP is a software development method based on frequent cycles, known for popularising a holistic set of 12 primary practices (later expanded to other secondary practices). XP Practice Area Primary Secondary Organisational • Sit together • Whole Team • Informative workspace • Real customer involvement • Team continuity • Sustainable pace Technical • Pair programming • Test-first programming • Incremental design • Shared code/collective ownership • Documentation from code and tests • Refactoring Planning • User stories • Weekly cycle • Quarterly cycle • Slack • Root cause analysis • Shrinking teams • Pay per use • Negotiated scope contract • Daily stand-ups Integration • 10-minute build • Continuous Integration • Test-first • Single code base • Incremental deployment • Daily deployment Agile and Lean Frameworks
- 81. Coincides with APG3.0 Feature Driven Development Feature driven development is an iterative model for developing software. It focuses on: • Developing an overall model • Building a features list • Plan by those features • Design by those features, and; • Build by those features. Feature Driven Development Develop high- level model Develop features list Plan by feature Design by feature Build by feature Iterate after feedback Agile and Lean Frameworks
- 82. Coincides with APG3.0 Feature Driven Development Feature driven development activities are supported by a core set of software engineering best practices: • Developing by Feature • Feature teams • Inspections • Regular builds • Visibility of progress and results • Configuration management • Individual class ownership • Domain object modelling Feature Driven Development Agile and Lean Frameworks
- 83. Auxiliary Agile andLean Frameworks
- 84. Coincides with APG3.0 Crystal Crystal Introduced by Alexander Cockburn in his book “Crystal Clear” and created at IBM in 1991, Crystal is an agile framework focusing on individuals and their interactions, as opposed to processes and tools (the first Agile principle). It is not a set process, but a guideline for team collaboration and communication. Three core beliefs: Technologies change techniques Cultures change norms Distances change communication Agile and Lean Frameworks
- 85. Coincides with APG3.0 Crystal Crystal Crystal is designed to scale, and realises that each project may require a slightly tailored set of practices based on size and complexity. Core Values Common Properties People Frequent delivery Interaction Reflective improvement Community Close communication Skills Personal safety Talents Focus Communications Easy access to expert users Technical environment with automated tests, configuration management and frequent integration. Agile and Lean Frameworks
- 86. Coincides with APG3.0 Crystal Crystal Sizing framework: Life (L) L3 L10 L30 L80 Essential Money (E) E3 E10 E30 E80 Discretionary money (D) D3 D10 D30 D80 Comfort (C) C3 C10 C30 C80 Number of people involved +- 20% 1 - 4 6-20 20-40 5-100 Crystal clear Crystal yellow Crystal orange Crystal red Crystal is designed to scale, and realises that each project may require a slightly tailored set of practices based on size and complexity. Agile and Lean Frameworks
- 87. Coincides with APG3.0 Dynamic Systems Delivery Method Dynamic Systems Delivery Method DSDM was designed to add more rigour to the rising iterative methods of the 1990s. It is most known for its emphasis on constraint-driven delivery, which sets Cost, Quality and Time at the beginning, then uses formalised prioritisation of scope to meet those constraints. Agile and Lean Frameworks
- 88. Coincides with APG3.0 Dynamic Systems Delivery Method Dynamic Systems Delivery Method Eight principles guide the use of the DSDM framework: 1. Focus on the business need 2. Deliver on time 3. Collaborate 4. Never compromise quality 5. Build incrementally from firm foundations 6. Develop iteratively 7. Communicate continuously and early 8. Demonstrate control (use appropriate techniques, prioritisation of scope, etc) Agile and Lean Frameworks
- 89. Coincides with APG3.0 Agile Unified Process Agile Unified Process The intent of AUP is to perform more iterative cycles across seven key disciplines, and incorporate the associated feedback before formal delivery. Discipline within a release Principles guiding the disciplines Model The team knows what it’s doing Implementation Simplicity Test Agility Deployment Focus on high-value activities Configuration management Tool independence Project Management Tailoring to fit Environment Situationally specific Agile and Lean Frameworks
- 90. Coincides with APG3.0 Behaviour Driven Development Behaviour-driven development allows a developer to focus on testing the code based on the expected behaviour of the software. It is a method of writing user stories. Specific behaviour-driven development frameworks can be used to define acceptance criteria based on the given/when/then format: • Given some initial context, • When an event occurs, • Then ensure some outcomes. Behaviour Driven Development Agile and Lean Frameworks
- 91. Scaling Frameworks Scrum ofScrums SoS Large Scale Scrum LeSS Scaled Agile Framework SAFe Enterprise Scrum Disciplined Agile DA Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 92. Scrum of Scrums Scrumof Scrums Similar to Projects, Programs and Portfolios, a “Scrum of Scrums” is conducted when two or more teams of three to nine members need to co-ordinate their work. A representative from each team attends a meeting with other team representative around three times a week. A representative from each team attends a meeting with other team representative around three times a week, to report on: • Completed work • Next set of work • Current blockers • Potential upcoming blockers The goal is to ensure teams are coordinating work and removing blockers across teams. Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 93. Scrum of Scrums Scrumof Scrums Scrum of Scrum of Scrums Scrum of Scrums Scrum Teams Notice how this aligns with the view of Projects, Programs and Portfolios in the PMBOK Guide. Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 94. Scaled Agile Framework(SAFe) Scaled Agile Framework SAFe focuses on a detailing practices, roles and activities at the portfolio, program and project levels, and focuses on organising the enterprise around value streams that provide value to the customer. Principles: • Take an economic view • Apply systems thinking • Assume variability, preserve options • Build incrementally with fast, integrated learning cycles • Base milestones on objective evaluation of working systems • Visualise and limit work in progress, reduce batch sizes, manage queue lengths • Apply the cadence for synchronising with cross-domain planning • Unlock the intrinsic motivation of knowledge workers • Decentralise decision making Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 95. Large Scale Scrum(LeSS) Large Scale Scrum LeSS aims to organise several development teams toward a common goal by extending the Scrum method across teams. Similarities of LeSS and Scrum LeSS Techniques Added to Scrum One single product backlog Sprint planning is more formally divided into two parts – what and how. One definition of done for all teams Organic cross-team coordination One potentially shippable product increment at the end of each sprint Overall cross-team refinement One product owner Overall retrospective focused on cross- team improvements Complete, cross-functional teams One sprint Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 96. Enterprise Scrum Enterprise Scrum EnterpriseScrum is a framework designed to apply the Scrum method at an organisational level, not just a single product development effort. It advises leaders to: • Extend the use of Scrum across all aspects of the organisation • Generalise the Scrum techniques to apply easily at those various levels • Scale the Scrum method with supplemental techniques as necessary Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 97. Disciplined Agile (DA) DisciplinedAgile Disciplined Agile is a process decision framework that blends various Agile techniques based on the following principles: People First Enumerating roles and organisation elements at various levels Learning-oriented Encouraging collaborative improvement Full delivery life-cycle Promoting several fit-for-purpose life cycles Goal-driven Tailoring processes to achieve specific outcomes Enterprise awareness Offering guidance on cross-departmental governance Scalable Covering multiple dimensions of program complexity Agile and Lean Frameworks Coincides with Agile Practice Guide 3.1
- 98. Delivering in an AgileEnvironment
- 99. Delivering in anAgile Environment Charter the Project and the Team A typical project using the Project Management Body of Knowledge (PMBOK) will initiate with a Project Charter. In addition using Agile, cross functional teams initiate with a Team Charter. The Team Charter Includes: • The project vision or purpose • A clear set of working agreements It answers these questions: • Why are we doing this project? • Who benefits and how? • What does “done” mean for the project? • How are we going to work together? A servant leader may facilitate the chartering process. Coincides with Agile Practice Guide 5.0
- 100. Delivering in anAgile Environment Charter the Project and the Team A team charter is also a “social contract”. It can include: • Team values, such as sustainable pace and core hours • Working agreements, such as what “ready” means so the team can take in work, what “done” means so the team can judge completeness consistently, respecting the time-box and WIP limits. • Ground rules, such as one person talking in a meeting, • Group norms, such as how the team treats meeting times. And other behaviours the team wants to work with or address. Coincides with Agile Practice Guide 5.0
- 101. Delivering in anAgile Environment Agile Teams Measure Results Agile favours value-based measurements instead of predictive measurements (like earned value management). By measuring what is done and replanning at each iteration by iteration, there is less room for error and more room to correct course. Coincides with Agile Practice Guide 5.0
- 102. Delivering in anAgile Environment Agile Teams Measure Results Some iteration-based projects use burndown or burnup charts to show where the project is going versus where it was planned. Many agile teams use story points to estimate effort. 0 10 20 30 40 50 60 1 2 3 4 5 6 7 8 9 10 Burn up chart (Story Points Done) Points Planned Actual 0 10 20 30 40 50 60 1 2 3 4 5 6 7 8 9 10 Burn down chart (Story Points Remaining) Points Planned Actual Coincides with Agile Practice Guide 5.0
- 103.
- 104. Organisational Considerations forProject Agility Evolving the Organisation When implementing a new hybrid or agile approach, it is recommended to undertake the work incrementally. Treat the change as an agile project, with its own backlog of changes that could be introduced by the team based on perceived value. Each of the changes can be treated as an experiment, tested for a short period of time to determine suitability or the need for further refinement. Use Kanban boards to track progress, showing new approaches in use as “done”, and things being tried as “in progress”. Coincides with Agile Practice Guide 6.8
- 105. Organisational Considerations forProject Agility Coincides with Agile Practice Guide 6.8 Evolving the Organisation You can assess the current culture and its readiness for agile, and tailor a solution to suit. One model you can use is below, but others exists and the main idea is to work with and understand the team. Often an agile approach will enable both ends of the priorities below. Exploration Execution Speed Stability Quantity Quality Flexibility Predictability (Other factors)
- 106.