Downloaded 19 times
More Related Content
Scrum for beginners
- 1. Scrum “A lightweight guideto the theory and practice of scrum” by Larman C., Deemer P., Vodde B. and Benefield G. (2012) Dmitrij Petrov | Sandra Daisy Wagner | Davorin Ristic
- 2. Agenda 1. Scrum Overview 2.Scrum Roles 3. Workflow 4. Common challenges 5. Summary
- 3. Scrum Overview SCRUM OVERVIEW– SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 4. Scrum Team Just “teammembers” Maximizes ROI for customer Is a coach and a teacher Has high autonomy and accountability Identifies product features Helps the group learn & apply Scrum Builds shippable product each Sprint Has final decision authority Serves team in whatever is necessary SCRUM OVERVIEW – SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 5. Starting Sprint Product Backlog •“Product roadmap” of all items • Product owner makes their prioritization • DEEP: Detailed, Estimated, Emergent and Prioritized Sprint Planning Meeting • Part one: “what” – to understand PO’s needs and the rationale behind it • Part two: “how” – how to implement the items SCRUM OVERVIEW – SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 6. The Sprint Timeboxed to •1-4 weeks, intensive work cycle • Self managing Daily Scrum • Short, everyday and standing Dev. Team meeting • No discussions – just reporting about work • Use Sprint Burndown Chart ! SCRUM OVERVIEW – SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 7. Ending Sprint Sprint Review •Inspection & adaption related to product increment of functionality • Hands-on inspection of software that is running live Sprint Retrospective • Inspection & adaption related the process and environment • What’s is working (and not) • Don't focus just on problems SCRUM OVERVIEW – SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 8. SCRUM OVERVIEW –SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 9. Common challenges • Whenteams members are geographically dispersed, part-time etc. • A Scrum Team should have a close and ongoing interaction most of the time. • Teams with very specialized skills can also be a challenge • A Scrum Team should be able to work on any task or project • The PO does not necessary know e.g. the market or features. Or the team may be unskillful in the estimation of development work • Scrum quickly shows these weaknesses, i.e. it makes problems visible SCRUM OVERVIEW – SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 10. Summary • Scrum isa framework used for agile and iterative software development • Scrum Team has 3 members: Development Team, Product Owner (only 1) and Scrum Master (only 1) • Workflow is divided into Sprint Planning, Daily Scrum and Review & Retrospective • No silver bullet solving all development problems, rather gives transparency of work and continuous adaptation to environment SCRUM OVERVIEW – SCRUM TEAM – WORKFLOW – COMMON CHALLENGES - SUMMARY
- 11.
Editor's Notes
- #2 Scrum introduction We will present the Scrum Framework, which is a agile development framework. The presentation is based on the paper by Deemer and other “A lightweight guide to the theory and practice of scrum”. Source of image: http://www.ialglobal.com/uploads/blog_post/ScrumArrows1.png
- #3 First we would like to give a overview of the geometrical representation of the Scrum framework. Then we will go into more details about the different roles and how the workflow in the framework is. Lastly we will elaborate on challenges and finish with a summary.
- #4 First we would like to present the model for you and give you an overview, before we break it up into smaller pieces and go in more detail. The frameworks geometrical representation looks as you can see above. The framework has only 3 roles the Product Owner, a Team and a Scrum Master! The guys you can see in the model above are a cross-functional Scrum team and if they follow the process illustrated above, they will, be able to increase agility and adapt the development process to the changing corporate priorities. Without disturbing the beautiful minds of the cross-functional team. We will start by introducing the roles and then elaborate on the process starting from the left. Now Dimitry will go into more detail with the three roles you can see outlined above in yellow. ____________________________________________________ BELOW can be considered to be said as well: Source of image: http://ddi-dev.com/uploads/media/news/0001/01/d3e5ccef3f544c5c5135d6f988e4a820d5495904.jpeg
- #5 Ok, thanks. So, as Davarin has told you scrum, being an iterative software development framework, has 3 roles – Dev. Team which should not be lost somewhere, Product owner and Scrum master. They together are called scrum team and I want to briefly talk about each of them. PO is responsible for maximizing RoI by identifying product features, deciding which one should be at the top of list for next sprint and continues (re-)prioritization of items & (refinement) of list. Very importantly, given that product owner represents the customer – and in some cases it can be even the customer in the same person – only he or she has the final responsibility over when SW is done. A group of developers is usually around 10 people is a cross-functional software development team, i.e. it includes people with expertise necessary to build SW product. And such a group does all the work from analysis of what software PO wants to have, over the development itself and documentation and testing. These developers are highly autonomous in their decision making (it is them who choose items to work on in a sprint) and accountable for delivering shippable product each sprint. Lastly, we have Scrum Master, which can have any background, who helps the product group to learn and apply scrum. So it does basically whatever is necessary to help Dev team and product owner. SM serves the whole team and coaches and guides the PO + DEV to achieve desired results and facilitate the process itself. He also protects the dev team from outside interferences and help in adoption of modern development techniques. Finally, as you can see there is no project manager as none is needed -> dived and reassigned to PO and Dev team. Source of Images: http://images-cdn.9gag.com/photo/5443633_700b.jpg http://sd.keepcalm-o-matic.co.uk/i/keep-calm-and-trust-your-product-owner-4.png https://nsteane.files.wordpress.com/2012/03/top_ten_yda.jpg
- #6 So as davorin already told you, sprint (or an iteration) is a timeboxed unit of devleopment. This is usually between 1 to 4 weeks. Hej sandra The workflow looks like thise: PO gathers all the functional and non functional requreinemts, features, bugs (mistakes in a programm code) and prioritizes them based on risk, value etc. (Consider adding: He ’translate’ the corporate priorities/ into software development priority) And you maybe say something on the inputs from Executives, customers, users.. And you should talk about the planning meeting one and two more clearly i think? Then, once a backlog is created, the each new sprint starts with a planning meeting consisting of two parts to define so-called ”sprint backlog”. This is destilated version of what Dev. Team chooses to work on. The goal is here to estimate an effort and give a PO a forecast for difrernet items which by the end of sprint should be really done. The product backlog is ultimate responsibility of Product Owner, only he can modify it and a good Product Backlog is abbreviated as DEEP… Detailed appropriately. (The top priority items are more fine-grained and detailed than the lower priority items, since the former will be worked on sooner than the latter.) For example, the top 10% of the backlog may be composed of very small, well-analyzed items, and the other 90% much less so. Estimated. The items for the current release need to have estimates, and furthermore, should be considered for re-estimation each Sprint as everyone learns and new information arises. The Team provides the Product Owner with effort estimates for each item on the Product Backlog, and perhaps also technical risk estimates. The Product Owner and other business stakeholders provide information on the value of the product requests, which may include revenue gained, costs reduced, business risks, importance to various stakeholders, and more. Emergent. In response to learning and variability, the Product Backlog is regularly refined. Each Sprint, items may be added, removed, modified, split, and changed in priority. Thus, the Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth. Prioritized. The items at the top of the Product Backlog are prioritized or ordered in a 1-N order. In general, the highest-priority items should deliver the most bang for your buck: lots of bang (business value) for low buck (cost). Another motivation to increase the priority of an item is to tackle high risks early, before the risks attack you.
- #7 Focus “how much work remains in the future” Time boxed 1-4. Now everything is estimated and prioritized- and everyone is now commited and it is important to emphasise that the end date of the sprint can’t be changed, or the team deliverable. So everyone is committed. Frequent feedback No manager/self managing. This is where SCRUM differs from other agile methods Scrum have high self management. Forcasting By selfmanagement the team can better estimate/forcast The cross functional team understands better the difficulties presented by Brooks and therefor over time will be better and better to forcast. Daily sprint These are short meeting last 15 min and are done every day. At these meetings it is the “team” that are present and maybe the Scrum Master, which role is not to be a manager. The important thing is that the meeting build upon a reporting method. The team should report three things, 1) what is accomplished from the sprint backlog since the last meeting, 2) before next meeting and 3) obstacles. And it is important to emphasise that the meetings are not a status meeting reporting to a manager, so someone perceived as authority should not attend the Daily Scrum, because this will disturb the self managing idea. The purpose of the meeting is to update other Team member on the effort required to complete the Sprint Backlog. After everyone has reported the three things it is possible to do a more in depth meeting on e.g. obstacles the team faces reported from one of the members. Tracking Progress during the Sprint So the Sprint Backlog introduced earlier is a to do list for the team for the present sprint. This backlog is updated with the estimate of the effort remaining to complete it every day. So it is also very important to emphasize that the goal in the sprint on completion how much work remains, what the work is and how to do it and not in how much was spent in the past. Burndown chart The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. Aspects important to the Sprint These aspects that are important, how are they put into practice? The spirit of the Sprint goal is to get something tangible and “done” What has been accomplished since the last meeting? What will be done before the next meeting? What obstacles are in the way?
- #8 OK, now that Dev Team has finished their work, there are two important events that take place. The first one is the Sprint review where all members of scrum team, together with other stakeholders are present and the goal here is to insect and adapt activities for the product. Basically, to see what is happening, have in-depth conversation and then evolve based on the feedback. While Team informs what they have achieved or not, PO informs them about the changing environment etc.. The dev team also shows the live software, because don’t forget the goal of scrum is to have each sprint something tangible. What follows after that is the sprint retrospective, which inspects and adapts regarding the process and environement. And this is important because some e.g. processes or approaches may not be working very well and team needs to agree on changes. But dont forget that it is not just about problems – be, stay and talk about positives as well.
- #9 Starting the next Sprint! Briefly i would like to just give you an overview and some advantages to the Scrum framework. – LETS ASUME THE TEAM FINISHED THEIR FIRST SPRINT! Goal Working product Goal goal goal goal Working product Better way to learn and improve over time At the end of sprint you have something tangible. And you have this mechanism that ensures that the team can learn and evovle based on ”inspection and adaption” in relation to the product and - the proces and enviroment. This knowlegde can then be applied when planning the next sprint and inprove the Teams ability to forcast and understand what and how challgenges with the product are solved. Suppose the Team fails to deliver what they forecast in the first Sprint due to poor task analysis and estimation skill. To the Team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about its forecasts. This pattern – of Scrum helping make visible dysfunction, enabling the Team to do something about it – is the basic mechanism that produces the most significant benefits that Teams using Scrum experience. Helpshandlechangingrequirements&priorities Lowers cost of change Provides better visibility into project progress Reduces risk Maximizes returnon investment (business value prioritized) Encourages higher quality , simplercode Delivers business value early & often The product backlog creates a fundament for sprint planning meetings which try to plan the ”what” and ”how”. This then distulled into a sprint backlog for the individual sprint. At the end of each sprint you have something tangible. And you have this mechanism that ensures that the team can learn and evovle based on ”inspection and adaption” in relation to the product and - the proces and enviroment. This knowlegde can then be applied when planning the next sprint and inprove the Teams ability to forcast and understand what and how challgenges with the product are solved. Suppose the Team fails to deliver what they forecast in the first Sprint due to poor task analysis and estimation skill. To the Team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about its forecasts. This pattern – of Scrum helping make visible dysfunction, enabling the Team to do something about it – is the basic mechanism that produces the most significant benefits that Teams using Scrum experience.
- #10 Ok now something to challenges which Scrum posses. For one if teams are geographically dispersed, it can be hard to hold daily scrum meetings. In fact what many companies have decided to do is to move poeple around the globe just to follow proper Scrum pracises and not hold daily scrum over skype and similar. At the end of day, the face to face contact is still relevant. Scrum has some other challenges as well and what you will not find on this slide is for example the fact that given that it is just team members who are in development team, it is very hard to advance your career through following such a pracise. Indeed, if you are a very seniour software deveoper Scrum imposes indirectly non-hierarchy resultiing into dissatisfaction of such senior people. Everybody is member and thus to advance and become a vice president of engeering is really tough in such a environement. Lastly another point which is not on this slide but neverthelss I also want to mention is that making R&D with Scrum is really hard. That is not to say that you cannot use scrum for your PHD thesis or research and development of new exitiing services and products but given that Scrum is rather short-term oriented, 1-4 weeks, it forces you not to fail because at the end of every sprint you need to show something. So essentially there is no room to experiment. And so for senior people, there is no reason to go to work because they can solve every problem but cannot experiment with different kids of solutions. http://www.agileoverflow.com/t/why-do-some-developers-at-strong-companies-like-google-consider-agile-development-to-be-nonsense/107