Agile scrum introduction
•Descargar como POTX, PDF•
1 recomendación•793 vistas
Presentation used for Webinar 14. Sep. 2016
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Agile scrum introduction
Similar a Agile scrum introduction (20)
Último
Último (20)
Agile scrum introduction
- 1. Prepared By: Martin Vinther Copenhagen, 14. September 2016 AGILE & SCRUM AN INTRODUCTION
- 2. Martin Nymann Vinther Agile Consultant and Trainer vinther@ugilic.dk vinther@agileakademiet.dk (+45) 29 89 53 10 @MartinVinther
- 3. AGILE VS SCRUM september 2016 © Agile Akademiet . All Rights Reserved WHAT’S THE DIFFERENCE Agile is to Scrum what Beer is to Pilsner
- 4. GUIDING AGILE PRINCIPLES september 2016 © Agile Akademiet. All Rights Reserved WHY THESE ? • Knowing and following these guiding principles is essential for reach an Agile Mindset • Whatever process you follow it must comply to these principle Understan d together Plan together Execute together Demo early and often Reflect to learn
- 5. WHEN TO USE AN AGILE PROCESS THE SPECTRUM OF PROCESS COMPLEXITY Agile projects Structured projects Chaotic projects
- 6. CORE AGILE MINDSET, VALUES AND PRINCIPLES Agile Mindset Agile Values Agile Principles
- 7. UNLIMITED NUMBER OF PRACTICES Scrum eXtreme Programming SAFe Kanban for software Being Agile Doing Agile
- 8. A CONSTANT JOURNEY september 2016 © Ugilic. All Rights Reserved 8
- 9. AGILE MINDSET WE BASE OUR VALUES AND PRINCIPLES ON: • Ability to grow • Goal is to learn • Embrace challenge • Failure provides Learning Opportunity • Effort is the Path to Mastery • Reaction to challenge is Resilience Linda Rising
- 10. INIVIDUALS & INTERACTIONS WORKING SOFTWARE CUSTOMER COLLABORATION RESPONDING TO CHANGE PROCESS & TOOLS COMPREHENSIVE DOCUMENTATION CONTRACT NEGOTIATION FOLLOWING A PLAN OVER OVER OVER OVER THE AGILE MANIFESTO “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:” “That is, while there is value in the items on the right, we value the items on the left more.”
- 11. AGILE PRINCIPLES 12 CORE PRINCIPLES 1. Satisfy the customer through early, continuous delivery 2. Welcome changing requirements, even late 3. Deliver working software frequently 4. Business people and developers collaborate daily 5. Build projects around motivated individuals 6. Convey info via face-to-face conversation 7. Primary progress measure: working software 8. Maintain a sustainable pace indefinitely 9. Continuously demonstrate technical excellence 10. Essential to simplify; maximize amount of work not done 11. The best architecture etc. ermerge from self-organize teams 12. At regular intervals, the team reflects and tune behaviour
- 12. ”EARLY DELIVERY OF BUSINESS VALUE” Agile is… Alistair Cockburn
- 13. FOLLOW THE VALUE Everything decided (and locked) up-front X $ X X? Y A little decided up-front $ Something decided up-front Y $ ! ?
- 14. BIG BANG = BIG RISK Ref: Henrik Kniberg Cumulative ValueRISK ? Valu e
- 16. SCRUM GUIDE
- 17. THE BASICS OF SCRUM Product Backlog w/ PBIs Sprint Backlog w/ tasks Sprint 1-4 weeks Timeboxed Sprint Goal is fixed Team decides how much can be completed Sprint Planning w/ PBIs Product Owner Scrum Master Sprint Review Backlog grooming Daily standup Sprint Retrospective Development Team
- 18. SCRUM VALUES 18
- 19. THREE PILLARS Three pillars uphold every implementation of empirical process control: Transparency Inspection Adaptation That is, the centrality of communication, review and improvement
- 20. Prioritization Estimation Understanding The Product Backlog Iceberg Product Owner Sprint 1 Sprint 2 Sprint 3 Sprint 4 Development team Release Plan RELEASE PLANNING
- 22. 22 THANKS FOR LISTENING GET IN TOUCH VIA: VINTHER@UGILIC.DK TWITTER: @MARTINVINTHER (+45) 29 89 53 10 UGILIC.DK/VINTHER
Notas del editor
- Here’s the essentials of Agile and Scrum. The Agile Manifesto (”Individuals and interactions…”) was written in February 2001 in Snowbird, Utah – by 17 software development thought leaders. The Agile Manifesto has since had a major impact on the software industry – and has also influenced non-IT product development and inspired leaders in many areas. The meanings of the manifesto items on the left within the agile software development context are described below: Individuals and Interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming. Working software – working software will be more useful and welcome than just presenting documents to clients in meetings. Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important. Responding to change – agile development is focused on quick responses to change and continuous development. Twelve principles underlie the Agile Manifesto, including: 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 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 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
- Hvilken tror I er sværest her i Nykredit og hvillen
- BE PREPARED TO CHANGE DIRECTIONS IN ORDER TO: FOLLOW THE VALUE! By specifying ”just enough” up front, Agile enables projects to ”follow the value.” TRANSPARENCY and PREDICTABILITY are part of the Agile way of working. (Time and resources are fixed, only scope changes based on prioritised business value.) Today, there are long lead times, we’re spending lots of money, but nothing seems to happen or worse yet, you are not getting the value you are asking for/expecting. -------------------------------------- Waterfall The logical thing to do when starting a new project is to decide and specify everything up front. This is represented by the triangle where the overall (top of triangle) vision, goals, needs are specified – and also all the low level, specific requirements and solution descriptions have been decided, analyzed and specified (bottom of triangle). You have decided exactly where you want to go with the project, before you get started. You want to go to X! ”X – yes! That’s where we’re going.” But then you learn things along the way. This can be about the technology or about the business area. You might start to find out what the users really wanted – and then you start to question whether X is the place to go. It might fulfill the original comprehensive requirement specification, but it starts to seem unlikely, that this is the best solution for the users. So you think ”X – hmm – I’m not so sure anymore.” After more weeks or months, you probably start to get a better picture of where the real value is: ”Let’s go to Y! That’s where the value is!!” However, this is not so easy. Because if you change the course of the project, then you go against what was agreed up front, and it takes a lot of work to redo the requirements and/or to describe and agree on all the changes. Because of this hassle, people on projects with big requirements up front – often end up optimising to meet the requirements rather than optimising according to how the project can provide the highest possible business value. Agile with room for adaptation & learning The good news is that there’s another way of thinking about project and leading projects. In Agile projects, we acknowledge the fact that we initially cannot get our heads 100% around where the highest business value is. We accept that there will be learning along the way – and that it makes sense to react to this learning and adapt the project direction and plans accordingly. So instead of trying to understand and specify everything up front, we create an overall (top of triangle) understanding to begin with – and trust that we will learn and figure the rest out along the way. Then, we execute the project a little at the time – in ”sprints,” and after each sprint, we demonstrate what we have, get feedback, learn and adjust the course – steering the project in the direction of the highest possible business value.
- Scrum Values All work performed in Scrum needs a set of values as the foundation for the team's processes and interactions. And by embracing these five values, the team makes them even more instrumental to its health and success.Focus Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.Courage Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.Openness As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.Commitment Because we have great control over our own destiny, we are more committed to success.Respect As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect. - See more at: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles#sthash.DNINE0ts.dpuf
- Transparency; the process must be visible and clear to all stakeholders: A shared process and language A common ‘definition of done’ and of progress (or lack-of) towards ‘done’ Inspection; artefacts created, and the progress in creating them, are frequently inspected for variance by skilled inspectors at the point of work Adaptation; once unacceptable deviation is identified, the process or product must be adjusted as soon as possible to minimize further deviation
- Using the estimates of prioritised stories and the forecasts of the amount of work that can be delivered in each Sprint, which Stories will be in which Sprints, can be ‘roughed out’. The MoSCoW technique can be used to prioritise stories; those features that are a ‘Must have’, those that are a ‘Should have’, those that are a ‘Could have’ and those that are a ‘Won’t have’ Following the principle of ‘rolling-wave planning’ specific functions are assigned to the next couple of Sprints only. The key is agility, the release plan will need to respond to changing circumstances
- A Burndown Chart is a run-sequence chart that compares the Velocity (the expected rate at which Points or Ideal Days/Hours would be completed) with actual completion. In the example above a Sprint Burndown is shown. The blue line shows the forecast Velocity for the Sprint (200 Ideal Hours) divided equally across the Sprint. The pink line shows the actual hours outstanding at each day; the actual line being above the velocity line show that the team is completing work slower than forecast and that the Sprint is behind schedule.