Agile scrum introduction

Editor's Notes

• #11: 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
• #12: Hvilken tror I er sværest her i Nykredit og hvillen
• #14: 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.  
• #19: 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
• #20: 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
• #21: 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
• #22: 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.