Agile scrum introduction

download Agile scrum introduction

If you can't read please download the document

Transcript of Agile scrum introduction

PowerPoint-prsentation

Agile & ScrumAn introduction

Prepared By: Martin Vinther Copenhagen, 14. September 2016

Martin Nymann VintherAgile Consultant and [email protected]@agileakademiet.dk(+45) 29 89 53 10 @MartinVinther

Agile vs Scrumseptember 2016 Agile Akademiet . All Rights ReservedWhats the differenceAgile is to Scrum what Beer is to Pilsner

Guiding agile principlesseptember 2016 Agile Akademiet. All Rights ReservedWhy these ?Knowing and following these guiding principles is essential for reach an Agile Mindset

Whatever process you follow it must comply to these principle

When to use an agile processThe spectrum of process complexity

Agile projects

Structured projects

Chaotic projects

5

Core AGILEMINDSET, VALUES AND PRINCIPLES

Agile MindsetAgile ValuesAgile Principles

UNLIMITED NUMBER OF PRACTICES

ScrumeXtreme ProgrammingSAFeKanban for softwareBeing AgileDoing Agile

A constant journeyseptember 2016 Ugilic. All Rights Reserved8

8

AGILE MINDSETwe base our values and principles on:Ability to growGoal is to learnEmbrace challengeFailure provides Learning OpportunityEffort is the Path to MasteryReaction to challenge is Resilience

Linda Rising

INIVIDUALS & INTERACTIONSWORKING SOFTWARECUSTOMER COLLABORATIONRESPONDING TO CHANGEPROCESS & TOOLSCOMPREHENSIVE DOCUMENTATIONCONTRACT NEGOTIATIONFOLLOWING A PLANOVEROVEROVEROVERTHE AGILE MANIFESTOWe 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.

Heres 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 softwareWelcome changing requirements, even late in developmentWorking software is delivered frequently (weeks rather than months)Working software is the principal measure of progressContinuous attention to technical excellence and good designSimplicity- The art of maximizing the amount of work not done - is essentialSelf-organizing teamsRegular adaptation to changing circumstances Sustainable development, able to maintain a constant paceClose, daily co-operation between business people and developersFace-to-face conversation is the best form of communication (co-location)Projects are built around motivated individuals, who should be trusted

10

AGILE PRINCIPLES12 core principlesSatisfy the customer through early, continuous deliveryWelcome changing requirements, even lateDeliver working software frequentlyBusiness people and developers collaborate dailyBuild projects around motivated individualsConvey info via face-to-face conversationPrimary progress measure: working softwareMaintain a sustainable pace indefinitelyContinuously demonstrate technical excellenceEssential to simplify; maximize amount of work not doneThe best architecture etc. ermerge from self-organize teamsAt regular intervals, the team reflects and tune behaviour

Hvilken tror I er svrest her i Nykredit og hvillen11

EARLY DELIVERY OFBUSINESS VALUEAgile isAlistair Cockburn

12

FOLLOW THE VALUE

Everything decided(and locked)up-frontX$XX?Y

A little decidedup-front$

Something decidedup-frontY$

!?

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, were spending lots of money, but nothing seems to happen or worse yet, you are not getting the value you are asking for/expecting.

--------------------------------------WaterfallThe 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! Thats where were 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 Im not so sure anymore. After more weeks or months, you probably start to get a better picture of where the real value is: Lets go to Y! Thats 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 & learningThe good news is that theres 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.

13

BIG BANG = BIG RISKRef: Henrik KnibergCumulative CostCumulative Value

RISK

?Cumulative Cost

Value

14

INCREMENTAL DEVELOPMENT

Scrum guide

The Basics of Scrum

Product Backlogw/ PBIsSprint Backlogw/ tasks

Sprint1-4 weeksTimeboxedSprint Goal is fixedTeam decides how much can be completed Sprint Planningw/ PBIsProductOwner

ScrumMaster

Sprint Review

Backloggrooming

Daily standup

Sprint Retrospective

DevelopmentTeam

Scrum values18

Scrum ValuesAll 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.FocusBecause we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.CourageBecause we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.OpennessAs we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.CommitmentBecause we have great control over our own destiny, we are more committed to success.RespectAs 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.dpuf18

Three Pillars

Three pillars uphold every implementation of empirical process control: TransparencyInspectionAdaptationThat is, the centrality of communication, review and improvement

Transparency; the process must be visible and clear to all stakeholders:A shared process and languageA 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

PrioritizationEstimationUnderstanding

FineGrainedMediumGrainedCoarseGrainedThe Product Backlog Iceberg

Product Owner

Sprint 1Sprint 2Sprint 3Sprint 4Development team

Release Plan

Release Planning

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 Wont 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 circumstances20

burndown Chart

Sprint Burndown

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.

22

THANKS FOR LISTENINGGet in touch via:

[email protected]

TWITTER:@MARTINVINTHER

(+45) 29 89 53 10

Ugilic.dk/VINTHER