itedas Certified Scrum Practitioner Open Base Slide Deck

itedas Certified Scrum Practitioner Open Base Slide Deck
This set of slides covers the content of all three certification seminars The slide set only serves as a suggestion for creating your own slide set. Note: In addition, it can also be used as an element for self-study. Additional materials for download and information on the exam can be found at All images and icons can be protected by copyright. Therefore, check it before use. itedas Scrum Practitioner Open Base v syl3.x en01.00

Objectives After the seminar, you will have the necessary knowledge and skills for the Agil Framework and the Scrum Framework to ... represent and introduce the agile values and principles in your company. … work successfully in Scrum projects to achieve a common goal in a team. … to be able to take on the roles of Scrum Master if they are personally suitable. … to pass the itedas certified Scrum Practitioner Scrum certification exams. itedas Scrum Practitioner Open Base v syl3.x en01.00

Recommended literature for deepening knowledge
[Schwaber, Sutherland 01] Ken Schwaber, Jeff Sutherland: Der Scrum Guide April 2017 [Pichler 01] Roman Pichler: Scrum. dpunkt.verlag 2008 [Rubin 01] Kenneth S. Rubin: Essential Scrum. mitp 2004 [Cohn 01] Mike Cohn: Succeeding with Agile. Addision-Wesley 2010 [Cohn 02] Mike Cohn: Agile Estimating and Planning. Pearson Education 2006 [Schwaber 01] Ken Schwaber: Agile Project Management with Scrum. Microsoft Press 2004, 23te Auflage 2016 [Lacey] Mitch Lacey: The Scrum Field Guide. Addision-Wesley 2012 [Pichler 02] Roman Pichler: Agile Product Management with Scrum. Addision-Wesley 2010 [Cohn 03] Mike Cohn: User Stories. mitp 2010 [Patton 01] Jeff Patton: User Story Mapping. O'Reilly 2014 [Dräther 01] Rolf Dräther: Retrospektive kurz & gut. O'Reilly 2014 [Löffler 01] Marc Löffler: Retrospektiven in der Praxis. dpunkt.verlag 2014 [Derby, Larsen 01] Esther Derby, Diana Larsen: Agile Retrospectives. The Pragamatic Programmers 2012 [Davies, Sedley 01] Rachel Davies, Liz Sedley: Agiles Coaching. mitp 2010 [Ries 01] Eric Ries: The Lean Startup. Portfolio Penguin 2011 [Schwaber, Beedle 01] Ken Schwaber, Mike Beedle: Agile Software Development with Scrum. Prentice Hall 2002 [Schwaber, Sutherland 02] Ken Schwaber, Jeff Sutherland: Software in 30 Days. John Wiley & Sons 2012 [Cohn 04] Mike Cohn: User Stories Applied. Addision-Wesley 2004 [Schwaber 02] Ken Schwaber: The Enterprise and Scrum. Microsoft Press 2014 [Adkins 01] Lyssa Adkins: Coaching Agile Teams. Addision-Wesley 2010 [Watts 01] Geoff Watts: Scrum Mastery. Inspect & Adapt 2013 [DeMarco, Lister 01] Tom DeMarco, Timothy Lister: Peopleware: Productive Projects and Teams. Addision-Wesley 2013 [Schwaber 03] Ken Schwaber: Nexus Guide August 2015 [SAFe 01] SAFe® 4.0 Introduction, A Scaled Agile, Inc. White Paper July 2016 itedas Scrum Practitioner Open Base v syl3.x en01.00

Zertifizierungsprüfung
Prüfungsart: Closed-Book-&-Clean-Desk-Prüfung (Literatur und Notizen dürfen während der Prüfung nicht verwendet) werden Weitere Materialen zum Download und Informationen zu Prüfung finden sich auf Hinweis: itedas Scrum Practitioner Open Base v syl3.x en01.00

Agenda Scrum: Foundation Scrum Project: Set-up
Background and Origin Empirical Process Control Agility Scrum, the Framework Scrum Project: Set-up Chose a Case Study (suggestion) to explain: Why and when agile / waterfall Who should take over which Scrum role and why Scrum Project: Product Planning Scrum Planning Principles Release Plan Product Backlog Scrum Project: Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Estimation and Velocity Estimation Concepts Estimation the amount of work Velocity Estimation Methods Steering Aspects Communication Monitoring Succession Planning Scaling Scrum Vertical / horizontal Scaling Working in complex / large Project Release Train Introducing Scrum Fundamental Approach Enterprise Transition Community (ETC) Reaction to Changes Introducing Agile Practices Coaching itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum: Foundation Background and Origin Empirical Process Control
Agility Scrum, the Framework itedas Scrum Practitioner Open Base v syl3.x en01.00

Magic triangle in project management
Quality Degree of fulfillment (number and depth) of the requirements for a solution Quality of the requirements implemented customer satisfaction Quality Cost Time customer satisfaction Degree of benefit perceived by the customer compared to the expected benefit of the delivered solution In order to be able to satisfy the customer, his requirements in terms of quality, costs and time must be met. Since every project is exposed to risks, one has to ask how the risks can best be managed. In all projects, certain tolerances or buffers must always be agreed. The buffers are either open to the customer (agile approach) or hidden, as in all so-called fixed price projects. In the case of the latter, the provider calculates a corresponding buffer. Tolerances / Buffer are necessary to get the project risks under control. A maximum of 2 corners of the magic triangle can be firmly agreed in order to be able to manage the project risks. itedas Scrum Practitioner Open Base v syl3.x en01.00

One method fits all? Business Processes Tunnel Highways Smartphones
Cars Smartphones Menues Subways Houses machine construction Airplanes Software Requirements expressed Project Use Project risk: How high is the certainty that the requirements once formulated are still valid at the end of the project? Can one and the same procedure (project method) always be correct for all projects? - No, because the requirements will change (in extreme: not at all) during the development period. Example of a slow change in requirements (and therefore suitable for a waterfall): S-Bahn station Munich Olympiastadion. Even if the Olympic Stadium is still in operation today, the stop built for the 1972 Olympic Games is now a ruined building. Modern, innovative products must be developed in an agile (= adaptive) manner, since a strong learning curve (=> potential changes in requirements) can be assumed here. itedas Scrum Practitioner Open Base v syl3.x en01.00

Volatility of requirements
Requirements change more or less over time: due to changes in the usage environment due to a better understanding of the task to be solved time Change of Requirements adaptive / agile approach Waterfall approach Development time itedas Scrum Practitioner Open Base v syl3.x en01.00

Waterfall vs. agile Approach
Analyze Design früherer Teilnutzen Coding Testing In Service Analyze Design Coding Integration Testing Betrieb itedas Scrum Practitioner Open Base v syl3.x en01.00

The right method for every task
More information on the web under the keyword „Cynefin“ Classification of tasks / problems Complex Afterwards you know everything better Patterns (cause-effect relationship) can be found through experiments Procedure (adaptive approach): Probe Sense Respond Examples Mars mission Development of Software / new Processes Simple Fact-based Management clear cause-and-effect relationship Procedure (applying recognized best practices): Sense Categorize Respond Examples prefabricated house assembly line production Complicated expert knowledge The cause-effect relationship can be discovered, but is not immediately obvious Procedure (applying good practices): Sense Analyze (Expert knowledge) Respond Examples Debugging Chaotic crisis management no knowledge of the cause / effect relationship Procedure Act Sense Respond Examples banking crisis empirical process control Scrum itedas Scrum Practitioner Open Base v syl3.x en01.00

Empirical Process Control
Adaptive Approach: Probe – Sense – Respond 1 2 Accuracy in the range of centimeters (cm) Accuracy in the range of tenths of a millimeter (mm) 3 1971 (Intel 4004): Accuracy in the range of a few micrometers (µm) 1 m 1 cm 1 Quelle: 10.September :20 The Intel 4004 is a 4-bit microprocessor from the microchip manufacturer Intel, which was launched on November 15, It is the first single-chip microprocessor to be mass-produced and sold on the open market. It is usually referred to as the first microprocessor at all, which is not correct, since a microprocessor was developed at Texas Instruments in 1968 as a commission, but it never went into series production. 0,1 mm 2 1 µm 3 itedas Scrum Practitioner Open Base v syl3.x en01.00

„The New New Product Development Game“
Roots: First findings „The New New Product Development Game“ Harvard Business Review Januar 1986 „ The ... (sequential) 'relay race' approach to product development ... can conflict with the goals of maximizing speed and flexibility. In contrast, a holistic or 'rugby' approach - with which a team as a unit tries to make up ground - can better meet today's competitive requirements. ” 6 characteristics for a holistic approach to product development: built-in instability => release creativity self-organizing teams => working like a start-up company, freedom, dynamism, taking risks overlapping development phases => shorter development time "Multilearning" => cross-team and cross-functional subtle control (control without pressure, "everyone controls everyone") Transfer of what you have learned to the organization In dem 1986 im Harvard Business Review Magazin erschienen Beitrag beschrieben Takeuchi und Nonaka das Ergebnis einer Studie zur Erforschung von modernen Produktentwicklungsstrategien bei namhaften Unternehmen in Japan und den USA. Sie kamen zu dem Schluss, dass eine moderne Produktentwicklung einen holistischen Ansatz mit sechs Charakteristiken (siehe Folie) folgt. Zitat: “In this article, we highlight companies both in Japan and in the United States that have taken a new approach to managing the product development process. Our research examined such multinational companies as Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard. We then analyzed the development process of six specific products: • FX-3500 medium-sized copier (introduced by Fuji-Xerox in 1978) • PC-10 personal-use copier (Canon, 1982) • City car with 1200 cc engine (Honda, 1981) • PC 8000 personal computer (NEC, 1979 • AE-1 single-lens reflex camera (Canon, 1976) • Auto Boy, known as the Sure Shot in the United States, lens shutter camera, (Canon, 1979) We selected each product on the basis of its impact, its visibility within the company as part of a “breakthrough” development process, the novelty of the product features at the time, the market success of the product, and the access to and availability of data on each product.” Die 6 Charakteristiken finden sich heute in Scrum wieder: Eingebaute Instabilität => Kreativität freisetzen = User Story, die dem Dev-Team Raum gibt Selbstorganisierende Teams => Arbeiten wie ein Start-up Unternehmen, Freiheit, Dynamik, eingehen von Risiken Überlappende Entwicklungsphasen => Kürzere Entwicklungszeit “Multilearning” => Team- und Funktionsübergreifend Subtile Steuerung (Steuerung ohne Druck, „jeder steuert jeden“) Transfer des Gelernten in die Organisation Much of it can be found in Scrum today. Syl_ID_1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

The market demands agility
Time2Market: The world is turning faster, and faster, and agile process models are ideal for providing solutions for customers or internal departments even faster. MVP – Minimum Viable Product: Requirements change so quickly that trying out solutions and approaches seems inevitable. On the one hand, requirements that seem plausible today may no longer be in demand tomorrow, and on the other hand differences in perception between the people involved can never be ruled out. Apple iPhone 2007 iPhone 1 2008 iPhone 3G 2009 iPhone 3GS 2010 iPhone 4 2011 iPhone 4s 2012 iPhone 5 2013 iPhone 5s 2013 iPhone 5c itedas Scrum Practitioner Open Base v syl3.x en01.00

Empirical Process Control
Scrum is based on empirical process control. Knowledge is gained from experience and decisions are made based on what is known. Scrum uses an iterative, incremental approach to optimize forecasting certainty and control risks. Empirical Process Control Transparency Inspection Adaptation For classic process control, it is necessary that the input in the process can be processed in such a targeted manner that a desired result can be generated repeatedly (= clear cause / effect relationship). In rapidly changing or complex environments, it can be impossible or at least very difficult to determine a clear cause / effect relationship, or it can be necessary to readjust the process again and again in order to be able to establish a clear process control. In these cases, empirical process control has its advantage. The empirical process control relies on verification and adjustment (which requires sufficient transparency) so that the process can not only control the processing of the input but also itself. Syl_ID_1.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Empirische Prozesssteuerung und Scrum
Transparency This ensures that the essential aspects of the work process are defined according to a common standard so that the stakeholders share a common understanding of what they see. Inspection The scrum artifacts and progress must be checked regularly to ensure that the sprint goal has been achieved. Adoption Adjustments (workflow, decisions, etc.) must be made as quickly as possible so that further deviations can be minimized. Scrum prescribes four formal events for Inspection and Adoption: Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Syl_ID_1.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum: values - basis for trust
Empirical Process Control Scrum Values Courage to do the right thing Focus on sprint work Openness in dealing with all matters of work Respect in dealing with each other Commitment to achieve the goals of the Scrum team T R U S Transparency Inspection Adaptation If the values of self-commitment, courage, focus, openness and respect are embodied and lived by the Scrum team, the Scrum pillars of transparency, review and adaptation come to life and build trust among all those involved. The members of the Scrum team learn and research these values by working with the Scrum events, roles and artifacts. The successful use of Scrum is based on the fact that everyone involved becomes more competent in fulfilling these five values. You personally commit to achieve the goals of the Scrum team. The members of the Scrum team have the courage to do the right thing and work on difficult problems. Everyone focuses on the sprint work and the goals of the Scrum team. The Scrum team and its stakeholders agree to deal openly with all aspects of their work and the associated challenges. Scrum team members respect each other as capable, self-reliant individuals. Syl_ID_1.6 itedas Scrum Practitioner Open Base v syl3.x en01.00

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Syl_ID_1.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

12 Principles behind the Agile Manifesto (1/2)
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Businesspeople and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Quelle: Syl_ID_1.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

12 Principles behind the Agile Manifesto (2/2)
Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Quelle: Syl_ID_1.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

What makes development agile
Each iteration provides functional software (seventh principle of the agile manifest). Faster business benefits. In each iteration, each phase takes place almost simultaneously. Bad developments can be quickly identified and corrected. The team uses specific development methods that allow the code base to be kept up to date and flexible. Short-term changes can also be taken into account. Teams act in a self-organized manner. Less overhead and red tape; quick decisions. Applying lean principles and techniques. Elimination of waste and concentration of resources on the actual goal increase in efficiency. itedas Scrum Practitioner Open Base v syl3.x en01.00

"Agile" only works on the basis of "Lean"
Empower your Team! See the whole Decide responsibly! Eliminate Waste! Deliver fast! Build in integrity! Strengthen Learning! Quelle: M & T Poppendieck, Lean Software Development : Eleminiere Verschwenung (Eliminate Waste): Eliminate… …Anything that doesn’t add value (as perceived by the customer) to the product …Unnecessary code or functionality …Unclear requirements …Slow internal communications or processes …Bureaucracy Stärke das Lernen (Amplify Learning): Realization of purpose of use rather than conforming to requirements Not intended to produce repeatable results, but to create solutions to unique customer problems Design is done best using discovery solutions: short, repeated cycles of investigation, experimentation and checking results We like to Try it, Test it, and Fix it! Knowledge generation (or feedback) loops are critical Verantwortungsvolle Entscheidungen (Responsible Decisions): Decide as late as possible to be open to latest requirements. Schnelle Lieferung (Fast Delivery): Customers like rapid delivery. Look at how UPS and FedEx … Rapid delivery means less time for customers to change their minds Empower Team A mature organization looks at the whole system; it doesn’t only focus on optimizing disparate or separate parts. A mature organization focuses on learning effectively and empowers the people who do the work to make decisions. Bauer Integrität ein (Build Integrity in): Perceived Integrity: is affected by the customer’s whole experience of a system Conceptual Integrity: means that system’s central concepts work together as a smooth cohesive whole Sehe das Ganze (See the Whole): Systems Thinking & System Dynamics The cornerstone of a lean organization Quelle: Jeff Sutherland, The Roots of Scrum 2010 itedas Scrum Practitioner Open Base v syl3.x en01.00

described by 12 Principles
„Agile“ is a Mindset based on 4 Values described by 12 Principles itedas Scrum Practitioner Open Base v syl3.x en01.00

Definition: Scrum A Framework within which people can tackle complex adaptive tasks and by being able to deliver products with the highest possible value productively and creatively. Syl_ID_1.5 itedas Scrum Practitioner Open Base v syl3.x en01.00

The rules are discussed in the context of roles, events and artifacts.
Scrum … is a framework for the development and maintenance of complex products, within which different processes and techniques can be used is lightweight, easy to understand, difficult to master. consits of Roles, Events, Artefacts and Rules, that connect the individual elements. Roles: Das Scrum-Team Events (Time Box) Sprint (max. 4 Weeks) Sprint Planning (max. 1* Day = max. 8* hours), Daily Scrum (max. 15 minutes) Sprint Review (max. 4* hours) Sprint Retrospective (max. 3* hours) Artefacts Product Backlog Sprint Backlog Increment Definition of Done Product Owner Entwicklungsteam Scrum Master * The times are reduced for shorter sprints. The rules are discussed in the context of roles, events and artifacts. Syl_ID_1.5 / Syl_ID_3.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum: events in the sprint process
Daily Scrum Planung Review Sprint Backlog Increment Retrospective Product Backlog An increment is only ready and potentially ready for delivery if it corresponds to the definition of done! planning development Review Retrospective maximal 4 weeks Syl_ID_1.5 / Syl_ID_3.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Advantages of Scrum Organizations that engage in Scrum benefit from the learning curve of all stakeholders and regularly inspire their customers by delivering what they want and not “only” what was set once on the first day. Additional advantages: improved returns through more frequent smaller releases Reduced costs by improving poor organizational processes quicker use thanks to operational increments Confidence in being successful in a complex world Enjoy working through close collaboration, which leads to improved interpersonal relationships and greater mutual trust Syl_ID_1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

6 agile principles (beliefs) on which Scrum is based
The future brings new insights 1 Prediction and adjustment 2 Validated learning 3 Work in Progress (WIP) 4 Progress 5 Performance 6 Syl_ID_1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

1. The future brings new insights
Scrum takes advantage of variability (learning curve) and uncertainty (new territory) in product development to create innovative solutions by … approaching the solution in small units (increments) (iteration). reacting to changes through empirical process control (review, adaptation and transparency). readily accepting helpful changes. simultaneously reducing all forms of uncertainties in product development. Uncertainties End uncertainty (what uncertainty): What exactly should be developed? Method uncertainty (how uncertainty): How (with which method / according to which concept) should be developed? "One-size-fits-all" problem; in the case of a waterfall, too little flexibility due to an early determination. Customer uncertainty (who uncertainty): For which target group / use cases should be developed? Syl_ID_1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

2. Prediction and adjustment
In particular, serious decisions should only be made when there is an adequate knowledge base. Or if they can no longer be delayed. At Scrum, the desire for prediction is constantly weighed up against the need for adaptation by keeping options open, preferring an adaptive, investigative approach and considering when and where an adaptive or predictive approach is more suitable. For this it is necessary that everyone knows that we will learn about the entire project and therefore know that not everything can be done right the first time. changes to be accepted in an economically viable way. During the development of innovative products, it is necessary to use prototypes (or similar) to verify or falsify ideas in order to gain new (valid) knowledge. Guess Chaos predictive Festlegungen adaptive Determining too early (= determining without knowing all the facts) leads to guesswork and to determinations that do not necessarily correspond to the “real” requirements (which will only be recognized at a later point in time through a learning path). Defining known requirements too late leads to the subsequent adaptation of solutions to “already” known requirements. This drives up costs, causes discontent among all stakeholders and leads to a negative perception of the development team and the product. Further information on the topic of "Prediction and Adjustment" can also be found under the term "Last Responsible Moment", coined by Poppendieck 2003. Changes are normal. Scrum tries to keep the cost curve for changes flat for as long as possible so that changes can be implemented cost-effectively for as long as possible. Syl_ID_1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

3. Validated learning Validated learning means acquiring knowledge that confirms (verified) or refutes (falsified) an assumption we have made (hypothesis). The following procedure is necessary for this : Validate important assumptions quickly Use of learning loops to support a constant learning process Organization of the workflow for quick feedback Hypothesis state of knowledge Test Syl_ID_1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

learning curve Risk Knowledge Iterations Samuel Beckett (1906–1989)
itedas Scrum Practitioner Open Base v syl3.x en01.00

4. WIP: Work in Progress To be able to deliver a quick benefit (and thus also receive quick feedback), it makes sense to limit the number of the work packages (batch size) being processed. Choosing a reasonable batch size Recognize inventory (= increments not delivered) and manage them sensibly Concentration on unfinished work and not on “inactive” people Consider costs and disadvantages caused by work packages that are delivered too late Advantages of correctly selected batch sizes: reduced cycle time: we are getting faster constant working speed faster feedback reduced risk reduced overhead because fewer activities need to be managed increased motivation and responsibility of the individual Syl_ID_1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Start a lot of work or get a lot of work done?
Situation: 40 work packages of 8 hours of work are waiting to be processed. All work packages have the same urgency (= same completion date). 10 work packages have a high priority (= 1). All other work packages have a priority of 2 or 3. An average of 4 net working hours per day are available to implement the work packages. All priority 1 work packages are started and processed. Approach 1: After 10 days, half of all 10 work packages are finished The customer has no benefit. Approach 2: Only 5 priority 1 work packages are started and processed. After 10 days, 5 work packages are finished. The customer has a benefit. With the right choice of a processing limit (work in progress limit), the customer receives the maximum possible benefit. itedas Scrum Practitioner Open Base v syl3.x en01.00

5. Progress Progress is measured by what is really finished and validated (DoD). Not what is in a predefined (phase) plan. In order to be able to react appropriately to current situations, planning is carried out continuously on the basis of real-time information over the entire development period. Progress measurement based on validated increments Concentration on a value-centered delivery of the increments Time Delivered benefit Scrum Project Waterfall Project Syl_ID_1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

„Don't burn out you should!“
6. Performance Go quickly, but don't rush. Build quality. Do everything without a big ceremony. Quelle: licensed under the Creative Commons Attribution-Share Alike License 3.0 (Unported) (CC-BY-SA) „Don't burn out you should!“ On Master Yoda listen you should. Build in quality: Quality begins with the first step and not only with the test. So try to get it right right away. Do everything without a big ceremony: speak to your neighbor rather than file notes or similar. mess. Agility and Scrum are based among other things on efficient communication from person to person! „Quality, the good side of the power.“ „Formalities often slow you down.“ Syl_ID_1.3 / Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Scrum Foundation
Background plan-based approach (waterfall) / agile approach Roots: first findings the market demands agility empirical process control Manifesto for agile software development Scrum Overwiev: Framework, roles, events and artifacts 6 agile principles (beliefs) on which Scrum is based : Changeability and uncertainty Prediction and adjustment Validated knowledge (learning) WIP: Work in Progress Progress Performance itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum Project: Set-up Comment:
Chose a Case Study (suggestion) to explain: Why and when agile / waterfall Who should take over which Scrum role and why itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum: The Stakeholder Family
Manager other Stakeholder Scrum Master Development Team Business Product Owner The role of "manager" takes on the role of resource manager and serves to provide all the necessary resources (personnel, rooms, infrastructure, etc.) The role of “other stakeholders” serves as an indication that besides the business there are also customers (=> €) and users (= users of the solution) or similar. could be. itedas Scrum Practitioner Open Base v syl3.x en01.00

The Scrum Team: different Roles, one Goal!
Product Owner Development Team Scrum Master Scrum Teams … are self-organizing and interdisciplinary. decide for them self how best to do your job. have all the skills required to get the job done. are able to optimize flexibility, creativity and productivity. deliver products iteratively and incrementally, maximizing the opportunity for feedback. Syl_ID_4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum Teams deliver Quality
Scrum teams ensure the desired quality right from the start. For Scrum teams, testing is a central component of the development process (and not something that happens after development (“done”)). Features for "built-in" quality (quality from the start): Use of quality-enhancing development techniques such as pair programming or in-depth code review / inspection Seamless collaboration between the people who program and those who test On the first day of a sprint there are "as many" tests as on the last day Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

The Product Owner Product Owner Is accountable* for the economic success and value maximization of the product. Is accountable* for the value-adding work (Product Backlog) of the development team. Is accountable* for the product backlog. Is a single person, not a committee. Can only be successful if its decisions are respected in the organization. The decisions of the Product Owner are visible in the content and order of the Product Backlog. * In the sense of the RACI model Syl_ID_4.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Universum des Product Owner
Stakeholder Business expertise: represents all stakeholders conveys the product vision strategic alignment (business / development) Prioritizing investments responsible for ROI Business Technology Social Development Team Scrum Master Technical Competence: Requirements management Management of the prioritized product backlog Planning and release management Accepting or rejecting sprint results Monitor progress Conducting reviews Universum des Product Owner Der PO muss sich stets in zwei Richtungen (Business&Stakeholder sowie Entwicklungsteam&ScrumMaster) orientieren. Social Skills: Motivation of the team responsiveness ensures that decisions can be made at the lowest possible hierarchical level Resolving team doubts about the project Syl_ID_4.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Main tasks of the Product Owner
Organization of economic concerns Participate in the planning Maintenance of the Product Backlog Definition of acceptance criteria and verification of their compliance cooperation with … Development Team all Stakeholders Syl_ID_4.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

User Interface (UI) design
The Development Team … is able to implement all types of activity that are necessary to create an increment. Code programming Data Base design Code testing Architecture design peparing Documentation User Interface (UI) design Server management Syl_ID_4.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

! The Development Team consists of professionals …
who hand over a finished increment at the end of each sprint, which is potentially deliverable. is structured and empowered to organize and manage its own work. The resulting synergy optimizes the overall efficiency and effectiveness of the development team. is always accountable as a whole. knows no dedicated titles like architect, tester etc.: „No ranks, no titles“. is small enough to stay nimble and big enough to get the job done in a sprint. consists of 3–9 members. If the Product Owner and Scrum Master also do work from the Sprint Backlog, they are part of the development team. Large development teams create too much complexity to be managed through an empirical process. ! Syl_ID_4.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

The main tasks of the Development Team
Carry out sprint Participation in the daily scrum (daily examination and adjustment) Maintenance of the product backlog (refine, estimate, if necessary, create and prioritize) Plan sprint Examine and adapt product (sprint review) and process (retrospective) Syl_ID_4.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

The main features of the development team
self-organizing versatile across functions T-shaped skills right size focused and committed Musketeer setting transparent communication broadband communication sustainable work pace durable, so that a real team can emerge from a group -shaped Skills B R O A D D E P „One for all, all for one.“ in the team interdisciplinary with Scrum Master with product owner frequency Use "osmotic" communication fast and efficient openness Syl_ID_4.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Development Team: Mission
Organize yourself! Estimate, estimate, estimate! Ensure quality! Deliver, deliver, deliver! Commit oneself! Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

The Scrum Master is responsible for understanding and executing Scrum.
does this by ensuring that the Scrum team understands and follows Scrums … Theory, Practices Rules helps to optimize the collaboration in such a way that the value generated by the Scrum team becomes maximum. Acts as a Servant Leader for the Scrum team. Syl_ID_4.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum Master: Servant Leader for
… the Development Team Coaching and Support … in everyday work. when introducing Scrum Remove obstacles (impediments) Support in the execution of Scrum events … the Product Owner Providing techniques for effective product backlog management Create an understanding of product planning in an empirical work environment Provide the right understanding of agility and its application Support in the execution of Scrum events … the organization Leading and coaching the introduction of Scrum Planning Scrum implementations Helping stakeholders understand Scrum Syl_ID_4.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

The main tasks of the Scrum Master
Coach for development team and product owner Servant Leader Process authority (Scrum values, principles and practices) protects the development team from disruptive influences Eliminate obstacles unless the development team is able to do so Organizational development consultant for the Scrum team and stakeholders (ensures the success of Scrum in the organization) Syl_ID_4.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

The main features of the Scrum Master
competent curious patiently team-minded Expertise: Scrum Good understanding: Technology: technologies, problem solving etc. Business: product planning, economy etc. Curious Interested in what's going on Initiate conversations to stimulate the conversation partner to think Discuss questions, but try to get the experts to come up with a solution themselves Protective Protects the Scrum team ("herding dog", "bodyguard") Transparent He makes his communication transparent and influences the team to do the same. Patiently The team (the experts) must come up with a solution themselves; the Scrum Master should not provide a solution. protective transparent Syl_ID_4.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Where's the project manager?
The Scrum Team: different Roles, one Goal! Product Owner Development Team Scrum Master Die Rolle des klassischen Projektmanagers teilen sich die einzelnen Rollen des Scrum-Teams itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Set-up Scrum: the stakeholder family The Scrum Team
Product Owner Development Team Scrum Master Role allocation in the case study itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum Project: Product Planning
Scrum Planning Principles Release Plan Product Backlog itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum Planning Principles
Plans cannot be right in advance. Planning ahead should be helpful, but not excessive. Organize planning inventory correctly Keep planning options open as long as possible- Fast learning and deviating from the plan if necessary Plans cannot be right in advance: Instead of planning everything at the beginning (-> uncertainties, the future may bring different facts / requirements / insights), Scrum follows its empirical roots, which are based on the principles of inspection and adaptation. Preliminary planning should be helpful, but not excessive: it is sufficient if the key points are clear at the beginning (=> Inspect & Adapt). The trick is to find the right balance between the predictions (decisions) made beforehand and the just-in-time adjustments. Organizing the planning stock correctly: Too much planning in advance harbors the great risk of wrong decisions in adaptive projects, which must be corrected later. Keep planning options open as long as possible / necessary: Decisions are best made when all information is known and the risk of making a wrong decision is the lowest. Fast learning and deviating from the plan if necessary: what has been planned in advance has to be adapted to new knowledge. Concentration on adapting instead of following a (fixed) plan: "Planning replaces chance with error" - errors should be corrected as quickly and as sustainably as possible. More frequent smaller releases reduce the risk: Small releases require less development time and resources and contribute more quickly to a positive cash flow. In addition, they enable faster feedback from the customer and allow a quick reaction to undesirable developments and / or changes in requirements. Focus on adapting instead of following a plan More frequent smaller releases reduce the risk. Syl_ID_5.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Advantage of smaller and more frequent releases
Zeit Returns Investments small Investments + early ROI + fast Feedback = reduced Risk Profit Phase Legende Investments Returns Syl_ID_5.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Multilevel Planning (Planning Onion)
Strategy Company Portfolio Stakeholder and Product Owner Product Product Owner, Stakeholder Release Scrum-Team (Product Owner, Scrum Master, Development Team), Stakeholder Sprint Scrum-Team (Product Owner, Scrum Master, Development Team) Day Development Team (Scrum Master) Syl_ID_5.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Portfolio Planning Portfolio planning is an activity in the course of which it is determined which products, in which order and over what period of time. Produktportfolio Comment: The portfolio consist of three products for different target groups „private user, small and large Companies itedas Scrum Practitioner Open Base v syl3.x en01.00

Planning at Product Level
Product Vision N Strategy Filter Idea Vision Finding Release Business other Stakeholder Product Owner Development Team Scrum Master As a rule, many specialists (product managers, marketing, sales, technical specialists, etc.) are involved in finding the vision. Syl_ID_5.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Product Vision: Wesentliche Merkmale
„ A vision is the art of making invisible things visible.“* A product vision captures the main features of the product. It provides the information that needs to be known and - more importantly - felt in order to develop and market a successful product. A product vision paints a picture of the future that attracts people. she describes, … who are the Customers, … their Needs … how these needs are met. An effective Product Vision … leads the Scrum Team and … connects Stakeholder to customer. * Jonathan Swift (1667–1745) itedas Scrum Practitioner Open Base v syl3.x en01.00

Product Vision: 5 questionstion to be answered
Who will buy this product? - Who is the target group? What customer needs are addressed with this product? What are the essential attributes and characteristics and thus the key success factors of the product to meet these customer needs? How does the product stand out from the competition? - What are the unique selling propositions (USPs) of this product? What are the timeframe and budget goals for product development and launch? itedas Scrum Practitioner Open Base v syl3.x en01.00

Product Vision: Elevator Pitch
In as little time as possible, the elevator pitch should present the product in such a way that the listeners are interested in the product and engage in a longer conversation. Structure of the elevator pitch : For <target group>, who <target groups demand>, is <product name> a/an <product category>, which <USP>. Different from <known product> stands out our product <Statement about the essential distinguishing features>. Example: For teenagers between 14 and 25, who want to get fit quickly after a night of drinking, is ThirstQuencher TQ a BIO energizer, which body and mind immediately return to full performance. Different from Red Bull it stands out our product with its 0-calorie content and a 100% natural spring water. itedas Scrum Practitioner Open Base v syl3.x en01.00

Case Study: Car2Ride a new Servcie @ Flitz!Auto
Product Vision: Elevator Statement For young people and companies, who want environmentally and cost-conscious mobility, offers Car2Ride a car sharing service, of the individual and simple kind. Different from SIXTY stands out our product is characterized by customer-friendly service with a good price-performance ratio and a high level of quality. Based on this product version, a first general overview with solution components (work packages) was created in the Car2Ride project. A necessary work package is the creation of a new website. After it was expected that the new “Gate to the World” from Flitz! Auto would have to be continuously adapted to the requirements and technical progress, the decision was made to implement an adaptive Scrum approach. Comments: As a rental car provider Flitz!Auto will add a new Car-Sharing-Service to its portfolio. Based on that scenario Flitz!Auto likes to launch a new Website. This undertaking is used a case study to build up a Product Backlog through the next couples of slides The elevator statement for the new service is very weak. Perhaps your class will find a better one. Collection of topics (brainstorming) for the website to be redesigned for creation of the product backlog. itedas Scrum Practitioner Open Base v syl3.x en01.00

Themensammlung für neue Website
Profiles: Here, members of the Car2Ride community should be able to create and manage their own profiles. Internationalization: The website should be available in all national languages. Order Manager: to manage rental contracts for rental and share cars Service chat bot: Visitors are addressed via a chat bot and can receive help in the chat. Car2Ride-Community Downloads: Download offer to determine service topics Accessibility: Die Oberfläche muss barrierefrei gestaltet sein. Was ist wichtig? Partner offers: As part of the planned partner program, partners should be able to present special offers. Homepage (Look & Feel) Was soll zuerst umgesetzt werden? Reviews: Here, vehicle users can rate cars and service. Events: List of events offered The redesign of the website can be started at an early stage. Only the topics marked in red can only be implemented in coordination with the progress of the Car2Ride project. Therefore, these topics will not be considered in the further course of the case study. With the topic "Accessibility" you can certainly add a gag regarding the booking of a car by a blind driver ... Area for premium customers with special information and offers Articles: Publication of editorially prepared press releases News: Announcement of news Supported Browser: the last 2 versions of IE, Firefox, Safari and Chrome Newsletter management for customers FAQs itedas Scrum Practitioner Open Base v syl3.x en01.00

The Product Backlog Collection of all requirements for the product to be created detailed functions Consists of differently detailed requirements Evolves throughout the project More detailed request packages („function groups“) Requirements that are to be implemented in one of the next sprints are more detailed than requirements that will only be implemented later. rough requirement packages („Modules“) The requirements are described in the form of user stories. As <Role>, I want <Target>, so that I <Advantage> itedas Scrum Practitioner Open Base v syl3.x en01.00

User Stories (Product Backlog) from Brainstorming
Events: As ... I want ... so that I ... Service-Chat-Bot: As ... I want ... so that I ... News - Subscribe to topic groups: As a visitor to the website, I would like to be kept up to date on certain current topics by so that I am informed. Order Manager: As ... I want ... so that I ... Newsletter-Management: As ... I want ... so that I ... Homepage (Look & Feel): As ... I want ... so that I ... News - topic groups : As a visitor to the website, I would like the topics to be grouped in clear groups so that I can quickly access the topics that interest me. Reviews: As ... I want ... so that I ... Articles: As ... I want ... so that I ... Area for premium customers: As ... I want ... so that I ... News: As a visitor to the website, I would like to be able to quickly see which current information is interesting for me at Flitz! Auto. FAQs: As ... I want ... so that I ... News: As ... I want ... so that I ... itedas Scrum Practitioner Open Base v syl3.x en01.00

Card Conversation Confirmation User Story = 3Cs Title
As <Role>, I want <Target>, so that I <Advantage> Conversation Dialog => necessary details! Development Team Product Owner Stakeholder Confirmation Conditions of Satisfaction (COS) ? Implementation OK NOK Syl_ID_3.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Gute User Stories sind „INVEST“
Independent: A story is independent of other stories. Negotiable: User stories are not a written law; if necessary, these can be changed in the consensus of the stakeholders. Valuable: Stories should deliver recognizable added value. Estimable: A story must be so clear that the developers can estimate the effort of the implementation. Small: The team has to decide on the specific scope of stories. As a rule of thumb, the implementation of a story should be between 0.5 and 10 person days. Testable: Stories must be testable. + not technically formulated itedas Scrum Practitioner Open Base v syl3.x en01.00

Product Backlog Items (BPIs): User Stories
The Product Backlog consists of user stories … with functional requirements with changes (improvements, concretizations, etc.) to already implemented functional requirements with technical improvements / adjustments (necessary updates) for troubleshooting (tickets) to acquire knowledge PW Reset As a user, I would like to have a PW reset if I forget it so that I can continue working. itedas Scrum Practitioner Open Base v syl3.x en01.00

Stories to acquire knowledge („Spikes“)
What we don't know, we have to prototypes, concepts, experiments or studies, etc. to find out. User Story As a developer, I want to know alternative solutions for the service chat bot to know which solution is the better choice in the long run. Confirmation Clarity should be achieved as to which solutions have a good price-performance ratio for our requirements. itedas Scrum Practitioner Open Base v syl3.x en01.00

Non-functional requirements and boundary conditions
Non-functional requirements represent qualitative requirements at the system level. Boundary conditions are requirements (e.g. legal) that limit the solution beyond what is necessary to meet the functional and qualitative requirements. Non-functional requirements and boundary conditions should be learned as early as possible. Non-functional requirements and boundary conditions are part of the Definition of Done (DoD). Qualitative requirements (ISO/IEC 25000) Security, accuracy Reliability (robustness) Usability (learnability) Performance changeability portability Example for a Website: Up to Pageviews per hour Up to simultaneously active users Support of the current and the last browser versions itedas Scrum Practitioner Open Base v syl3.x en01.00

Definition of Done (DoD
The definition of done lists all the work that must be completed before a potentially deliverable product increment can be declared finished. Example: Definition of Done  Design reviewed Code final Restructured Standard format Commented Checked in Code has been checked End user documentation updated… Tests carried out Unit Test Integration … no malfunctions found… Acceptance successfully tested Conditions of Satisfaction are requirements form a user point of view defined by the product owner, which an increment must meet. Syl_ID_3.6 itedas Scrum Practitioner Open Base v syl3.x en01.00

User story and possible other attributes
Name/Title (if necessary, plus a unique ID) User Story As a <Role> I need a <Functionality> so that I get the <Benefit>. Acceptance Criteria The acceptance criteria answer the question of what should be tested and ensure that a story can be accepted. technical (non-functional) requirements Mandatory requirements regarding architecture, implementation, monitoring requirements (heartbeat), dependencies. Dealing with code refactoring. Test Coverage (Environment (test, dev, prod), test data, test scenarios …) Additional Information Framework conditions to be observed, assumptions and exclusions, description of the initial situation, click paths, process / flow diagram, URL … Risks, that are associated with the (non) implementation (=> test concept) Dependencies to other stories / requirements / ideas Further Information Screenshots, mockups, documentation, interfaces ... as well as work processes, such as the following : „ Each new story must go through at least one round between the author and the developer in order to enable a uniform understanding. The user story is expanded, i. H. Details are described, acceptance criteria expanded, missing data (such as screens, test data etc.) added, answers to questions (in the description section) documented etc.“ Part of Definition of Done itedas Scrum Practitioner Open Base v syl3.x en01.00

Product Backlog Structure
As an editor, I need an area on the homepage in order to be able to place current announcements clearly visible to the visitor. … small User Stories Priority low high n 1 Days As an editor, I need an easy-to-use editing system (web content management system) that gives me the maximum freedom to place content. … (larger User Stories) Epics 1 n Weeks As a company, we need an attractive and modern homepage that fits our new image so that we appear credible to the outside world. … (large User Stories) Themes Epic is dashed because they are not always and necessarily made visible or used, as in the example of the website for Car2Ride. By "time period" is meant the implementation period Month Syl_ID_3.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

A good product backlog is „DEEP“
Detailed appropriately Emergent Estimated Prioritized itedas Scrum Practitioner Open Base v syl3.x en01.00

Management of the Product Backlog
Development Team Product Owner Stakeholder Even though maintaining the Product Backlog is a collaborative effort, the Product Owner is the only person who is accountable for managing the Product Backlog. Grooming of the Product Backlog Clearly formulate product backlog entries (PBI) Refine product backlog Sort (prioritize) entries so that goals and mission are optimally achieved optimize the value of the work that the development team does ensure that the product backlog is visible, transparent and clear to everyone and shows what the Scrum team will work on next ensure that the development team understands the Product Backlog entries as necessary Backlog grooming can take place at almost any time. It is only important that it fits well into the workflow of everyone involved. Syl_ID_3.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Product Backlog: Prioritizing and Sorting
Kano-Model Return on Invest (ROI) itedas Scrum Practitioner Open Base v syl3.x en01.00

The Kano Model: three kinds of product features
Basic Needs provided or expected subconsciously Fulfillment unnoticed / neutral attitude Failure creates dissatisfaction Examples: Hotel: room heating Car: doors open / close comfortably Performance Needs deliberately asked / required Degree of fulfillment ≈ degree of satisfaction Examples: Hotel: waiting times at reception, room size Auto: fuel consumption, engine power Delighters unexpected or even unknown Absence does no harm Fulfilled fulfillment Examples: Hotel: Jacuzzi in the room Auto: self-cleaning paint itedas Scrum Practitioner Open Base v syl3.x en01.00

The Kano Model and customer satisfaction
Delighters profitably arouse desires may need explanation Acceptance risk (example: non-alcoholic wine) Performance Needs are discussed cover costs neutral for purchase decision Very satisfied Degree of implementation of a characteristic absent / very bad complete / very good Basic Needs also meet competitors possibly not covering costs form knockout criteria temporal development : Delighters  Performance  Basic completely dissatisfied Syl_ID_5.3.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Determine the size of backlog entries
Sizes are estimated in Scrum Repeating the estimates over and over leads to better and better results Estimates are made in relative sizes, i.e. in relation to one or more reference sizes. As a rule, teams estimate this in story points or ideal days or ideal hours. Suitable scales: 1, 2, 4, 8, 16, 32, 64, 128 … 1, 2, 3, 5, 8, 13, 20, 40, 60, 100 … XXS, XS, S, M, L, XL, XXL The size of an entry is also a measure of the amount of work required to create this function. Syl_ID_5.3.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Product backlog prioritization based on “relative ROI”
Product Backlog Items rel. Benefit rel. Size rel. ROI Internationalization Order Manager Service-Chat-Bot Accessibility Downloads Partner Offers Area for premium customers Homepage (Look&Feel) Reviews Events Articles Supported Browser Newsletter Management Used scale: 1, 2, 4, 8, 16, 32, 64, 128 Non-functional requirements apply (usually) for all topics that are to be implemented. How it works: Put the requirements founded in the brainstoming session to an XLS-sheet (you can use the blue/grey one in the background) Remove all non-functional requirements because this has to fullfilled für each story. The Product Owner let the key stakeholder estimate the benefit of each story (= Theme/Epic) => choose any estimation technik you like In the next round the development team will estimate to size of each story/epic/theme. Let XLS calculate the rel ROI (Benefit/Size) Sort the list by the rel ROI and you‘ve one hint for sorting the stories/themes/epics. Product Owner Entwicklungsteam Stakeholder Syl_ID_5.3.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Produkt Roadmap (Release Planung) for the new Website
Area for premium customers Newsletter-Management Homepage (Look & Feel) Service-Chat-Bot Order Manager partner offers Reviews Downloads Articles Events Q2 Q3 Q4 Q1 Syl_ID_5.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Prepared product backlog
Product Owner So far planned Theme blocks (and / or epics) of the Product Backlog Homepage (Look & Feel) User Stories (Homepage) As Editor … I need a clearly visible area on the homepage to be able to place current announcements. I would like to have some freedom to place content in different places. … As visitor … I want to be able to see news at a glance. I would like to know about current promotions and offers. I want to have intuitive navigation through all areas. Articles Newsletter Management Downloads Service-Chat-Bot Reviews Events Order Manager Area for premium customers partner offers itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Produkt Planning
Scrum Planning Principles The Product Backlog Prioritizing Release Planning itedas Scrum Practitioner Open Base v syl3.x en01.00

Scrum Project: Sprint Sprint Planning Daily Scrum Sprint Review
Sprint Retrospective Syl_ID_2.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

The Sprint: The Heart of Scrum
The Sprint is a time box of a maximum of one month, within which a finished ("Definition of Done"), usable and potentially deliverable product increment is produced. All sprints within a development project should be of the same length. The new sprint starts immediately after the previous sprint is completed. Sprints are sometimes referred to as iteration. Each sprint includes the following events : Sprint Planning Daily Scrums Sprint Review Sprint Retrospective During the sprint … no changes are made that jeopardize the sprint goal. the quality standard is not reduced. the scope of requirements can be renegotiated based on new knowledge between the product owner and the development team. Syl_ID_2.1 / Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Aspects to consider for all sprints
Time Box short period of time consistent duration no changes affecting the goal Definition of Done itedas Scrum Practitioner Open Base v syl3.x en01.00

Timeboxing Timeboxing makes progress clear enforces prioritization
requires WIP limits prevents unnecessary perfectionism WIP limits limit the work to be started In order to do the right thing with a limited scope of work, it is necessary to prioritize the work packages The progress is visible after each sprint (= scope of the processed sprint backlog) Prevention of perfectionism: Due to the "shortage of time" you concentrate on what really needs to be done (definition of done) and do not try to enable the "platinum version" when "sheet metal" is required. Short periods of time with a clear deadline help not to lose sight of the goal and encourage you to finish. What can be done in 4 weeks is easier to predict than for a period of one year. improves predictability motivates completion itedas Scrum Practitioner Open Base v syl3.x en01.00

Duration: short and consistent across all sprints
Short period of time makes planning easier fast feedback limited mistakes improved return on investment enthusiasm frequent checkpoints Consistent duration => use of cadence In cadence, cadence is commonly understood to mean a whole sequence of harmonic functions that ends with a tonic ending (the actual cadence). The term cadence thus includes a functional arc of tension. Quelle: :12 Sprints of the same duration provide a cadence (a regular, predictable rhythm) for working. itedas Scrum Practitioner Open Base v syl3.x en01.00

The creation of a new website, the "gateway to the world"
The Sprint Goal describes the result (business purpose, benefits, etc.) of a sprint. The creation of a new website, the "gateway to the world" should be as short and clear as possible in order to clearly express the focus of the sprint. is the basis of the mutual obligation between the product owner and the development team. itedas Scrum Practitioner Open Base v syl3.x en01.00

Sprint Planning Planning the work for this sprint (= Sprint Backlog)
Attendees : Development Team Product Owner Scrum Master as a coach if necessary, also more, if required by the Development Team Scrum Master Product Owner Development Team Planning Sprint Backlog Product Backlog Sprint (max. 4 Weeks) Planning (max. 1 Day (8 h)) Daily Stand-up (15 Minutes) Review (max. 4 h) Retrospective (max. 3 h) itedas Scrum Practitioner Open Base v syl3.x en01.00

Evaluation / estimation
Planning Meeting Product Backlog DoR- Filter Product Backlog Scrum Master Product Owner Sprint Backlog Sprint Goal Development Team initial Sprint Goal constraints Evaluation / estimation ponder organize 8 Team Velocity DoR: Definition of Ready Syl_ID_3.2, Syl_ID_2.1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Definition of Ready (DoR)
In order to ensure that the user stories selected in the planning meeting can be implemented in that sprint, it makes sense to define the necessary preconditions. Beispiel: Definition of Ready  The business value / benefit is clearly articulated. The acceptance criteria are clear and testable. The development team understood the details correctly so that it is able to make an informed decision as to whether the story can be implemented in the sprint. No blocking dependencies were identified. The story is small enough to complete in the sprint. The Scrum team understands how to demonstrate product increment in Sprint Review. … Syl_ID_3.5 itedas Scrum Practitioner Open Base v syl3.x en01.00

Selection of the product backlog elements
If the product owner has specified a formal goal (Sprint Goal), the appropriate elements will be selected from the Product Backlog, otherwise the elements will be selected in order of the Product Backlog. Definition of Ready (DoR) Syl_ID_2.1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Sprint Planning: one-part / two-part approach
Free capacities allow further work? Select one BPI Determine Capacity Breakdown into tasks Refine Sprint Goal finalize commitment One-part Planning Determine Capacity Selection of all backlog elements up to the capacity limit Breakdown into tasks finalize commitment Auswahl der Backlog-Elemente anpassen Refine Sprint Goal Adjust Forecast Two-part Planning Formale Verpflichtung des Entwicklungsteam zur Umsetzung das ausgewählten Einträge. Syl_ID_2.1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

continuous task planning Implementation of the tasks
Sprint Execution continuous task planning Daily Scrum Flow Management Flow: A continuous workflow should be achieved. What must / can be processed in parallel or sequentially? What can / must be done in single tasking / multitasking? What is important is the continuous workflow and NOT the attempt to fully utilize all people at all times Implementation of the tasks Communication Syl_ID_2.1.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Decomposition: User Story -> Tasks
As <Role>, I want <Target>, so that I <Advantage> Task (technical) Examples for Tasks: Creating a database table Creation of a layout for the login screen Creating an HTML page to login Creating a CSS file for HTML page Creating a Java script for login Test the table and its links Test the layout of the HTML page … itedas Scrum Practitioner Open Base v syl3.x en01.00

Flow Management Single Tasking Multi Tasking or or Task Switching
House cleaning Watching TV Listen in House cleaning House cleaning Listen in Multi Tasking or or Watching TV Listen in Watching TV Task Switching HC TV LI HC TV LI Self-test: How much does task switching cost Write the following series of numbers as fast as you can. line by line (1, A, I – 2, B, II – 3, C, III … 10,J,X) Column by column (1,2,3 … 10, A,B,C … J, I, II, III … X) 1 A I 2 B II 3 C III 4 D IV 5 E V 6 F VI 7 G VII 8 H VIII 9 I IX 10 J X Single tasking: goes Multi-tasking: house cleaning and watching TV or listen to the radio (listen in) and watching TV is not possible Task switching works (maybe not always good). In any case, it costs time and should be reduced to a minimum Switching "between tasks can cost as much as 40 percent of someone's productive time." Quelle: itedas Scrum Practitioner Open Base v syl3.x en01.00

Flow Management and WIP-Limit
The Situation: 3 identical projects (P1, P2, P3); identical priority and urgency 3 resources (A, B, C) A takes 2 weeks B takes 3 weeks C takes 2 weeks the processing order is A, B, C Weeks P1 P2 P3 A A B B B C C WIP=3 Task-Switching-Mode A A B B B C C A A B B B C C P1 P2 P3 A B C Single-Task-Mode WIP=1 A B C A B C itedas Scrum Practitioner Open Base v syl3.x en01.00

Daily Scrum (Daily Stand-up) – „the small planning meeting“
daily meeting of the development team 15 minutes maximum Attendees: Development Team Scrum Master possibly silent (!) guests Purpose synchronization of the activities of the Development Team checking the progress towards the sprint goal helps the team achieve the sprint goal Daily Scrum Planning Sprint Backlog Product Backlog Three questions to be answered by each member of the Development Team: What have I achieved since the last Daily Scrum? What will I achieve by the next Daily Scrum? What obstacles do I see that could prevent me / us from reaching the sprint goal? Syl_ID_2.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Sprint Review The goal is to review what was created in the sprint (the product increment) and adjust the product backlog if necessary. Attendees: Product Owner (also invites stakeholders) Development Team Scrum Master important stakeholders Daily Scrum Planning Review Sprint Backlog Increment Product Backlog The sprint review is an informal meeting (no status report) in which the increment is demonstrated to the participants. The demonstration of the increment is intended as a suggestion for feedback and as a basis for cooperation. Syl_ID_2.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Elements of the Sprint Review
Product Owner invites stakeholders explains which product backlog entries are "done" represents the current status of the Product Backlog Development Team shows what went well during the sprint, what problems occurred and how they were solved demonstrates the “done” work and answers questions Scrum Master Stakeholder Assessment of the current (market) situation about new knowledge all participants work together on what to do in the next sprint (=> valuable input for sprint planning) Review the schedule, budget and potential characteristics of the next expected product release itedas Scrum Practitioner Open Base v syl3.x en01.00

Inspect & Adapt Inspect & Adapt
Sprint Retrospective the aim is, … to review how the sprint went in terms of people, relationships, processes, ways of working and tools. recognize the most important elements that went well. identify possible improvements and put them in order. create a plan for implementing the improvements. Daily Scrum Planung Review Sprint Backlog Increment Retrospective Scrum Master Product Owner Development Team Inspect & Adapt Inspect & Adapt Product Backlog Syl_ID_2.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Sprint Retrospektive: Input and Output
focus exercises objective data subjective data Insights Backlog Output: improvements Insights Backlog better collaboration better processes Scrum Master Product Owner Development Team Inspect & Adapt Inspect & Adapt Syl_ID_2.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Try The Ball Game to learn the power of Inspect & Adapt
Start Ball Point Game - Introducing Agile By The Fun Way Main Takeaways Reading Time: 4 minutes The Ball Point Game is a great opportunity to introduce people to basic agile principles and values in a fun and all-senses involving way. It simulates an agile production process. It is basically an analog of the scrum process. The team will self-organize and form a process based on the rules provided. The objective is to pass as many balls as possible in the given timeboxes through the team by following certain rules. The objective is to pass as many balls as possible in the given timeboxes through the team following certain rules. Dropped balls reduce as "defects" the final result. The game is a great opportunity to introduce people to basic agile principles and values in a fun and all-senses involving way. Are You Kidding, A Game? Imaging, you are an external coach or a corporate internal established Scrum Master, or an upper manager interested in this fuzzy stuff called "Agile". Now, imaging, on one day you should introduce a new team to the agile mindset as soon as possible, and with as less time as possible. And, middle managers and project managers will participate in addition. Seems to be an impossible assignment. How can you succeed? – But wait. Do not try it by giving the standard intellectual lecture and Powerpoint about agile values, agile principles, self-organizing teams, and all these buzzwords. Use a game instead. More precise, a physical agile game. Concrete, exercise the Ball Point Game, aka as Ball Flow Game. Stuart Brown's research shows playing is not just joyful and energizing – it's deeply involved with human development and intelligence. ((Stuart Brown is a medical doctor, psychiatrist, clinical researcher, and the founder of the US National Institute for Play.)) Playing is fun, even joyful. It refreshes and energizes us. And playing is a great tool for learning. For moments, you are involved with all your senses. You are involved with your complete body. Most importantly, you make many physical, and emotional experiences, and not only rational ones. Both brain hemispheres are involved, the left which controls the right side of the body, and is the more academic and logical side of the brain, and as well the left one which controls the left side of the body, and is the more artistic and creative side of the brain. How The Game Works Boris Gloger created The Ball Point Game in The game is a great opportunity to introduce people to basic agile principles and values in a fun and all-senses involving way. Trust – See how to build trust in the team and in individuals. Self-organisation – See how the team makes decisions to work best, without control from outside managers. Adapt & Inspect – See how the team steps back and reflects in retrospectives on a regular base to improve the own work. Timeboxed, incremental delivery – See how the team estimates, plans, and improves quality in an iterative manner. Agile ceremonies – Geting acquaintance with "Sprint", "Retrospective", "Planning", Estimation". Learning – See how fast the team succeeds. The game simulates an agile production process. It is basically an analogue of the scrum process. The team will self-organize and form a process based on the rules provided. The objective is to pass as many balls as possible in the given timeboxes through the team by following certain rules. Resources & Playground Needed Book a room large enough all participants can move around freely; remove all obstacles: chairs, tables, etc. You need a flipchart and a stopwatch. You need 100 balls like for kids ball pools. Group Size You play the game best with more than 6 participants. The more the best. If possible bring some observers to the game. They only observe from "the outside", they do not play. The Rules The rules are straightforward. To score a point: Everyone is part of one team. Each ball must have air-time. Each ball must be touched at least once by every team member. Balls can't be passed to your direct neighbor to your immediate left or right. Each ball must return to the same person who introduced it into the system. There are a total of five iterations. If you want, you can increase the experience by introducing "defects": If a ball drops and can be fetched it can be put into the game again. All balls not be fetched at the end of the iteration count as "defects" and are subtracted from the final result. Alternative: state a mechanism and "penalty" for dropped balls fed in the next sprint as additional work. How To Play In the game, there are two roles, only: the team, and the Product Owner (given by the facilitator). Here’s how to play the game. Allow the team to prepare and to determine how they will organize themselves. (2 min) Ask the team for an estimate how many balls they can pass through the system at the first run. Run the first iteration. (2 min) Allow the team to discuss how to improve the process. (1 min) Repeat for five iterations. Start with the third iteration to challenge/stress the team. Demand more than the team wants to deliver. If you need to, make up some ridiculous statistics such as “The world record is 150 points. Can you beat that?” – “If you don't give me 160 points I will go to your competitor <placeholder>” – “The last time I facilitated the game the team gave me 500 points.”– try to become a stressy, pain-in-the-ass, product owner asshole 😉 Document for each iteration all numbers at a flipchart and create a visual chart at end. Debriefing. Take as much time as needed to discuss the learnings and observations. My real-life experience: when the game takes 30 min, a very valued discussion afterwards may take 2 hours. Debriefing Possible questions for debriefing. What did you learn from the game? How did the team make decisions? How would things have gone differently if the team had an appointed leader? How important were retrospectives? Did you realize stress? – When? Why reduce dropped balls the final result? – Meaning of defect handling. Which team dynamics did you experience? Update 1.Dez, 2017 – Quotes from a workshop I ran with a client (in German): „Erstaunlich schnell hat das Team seine organisatorische Aufstellung alleine gefunden. Mit einem Manager hätte es langsamer gedauert.“ „Ich fühlte mich als Teil des gesamten Teams, obwohl ich auf meinen Bereich fokussiert war.“ „Ab einem bestimmten Punkt war ich in einer Art von Flow.“ „Wichtigstes Learning: die Bedeutung der Retrospektiven zum Lernen und ständigen Verbessern.“ „Obwohl der Spielleiter (Michael) immer höhere Ergebnisse forderte, haben wir uns (als Team) von ihm nicht stressen lassen.“ Downloads The ready out of the box Plays-in-Business Ball Point Game Package Full Game documentation by Boris Gloger Further Readings Excel Spreadsheet & VBA Code by Availagility, UK. A game variant: Retrospektive (Inspect & Adapt) 2 Minuten Vorhersage  Umsetzung 2 Minuten itedas Scrum Practitioner Open Base v syl3.x en01.00

A sprint ends automatically after the defined time (time box).
Ending the Sprint Normal Ende: A sprint ends automatically after the defined time (time box). Aborting a Sprint: A sprint can be canceled by the product owner (last decision-making body) before the time box expires if the sprint goal has become obsolete. Cleanup in the event of demolition: "Abort review": Assessment of all "done" increments and, if necessary, acceptance by the Product Owner Re-estimate all incomplete increments Grooming of the Product Backlog itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Sprint Sprint Planning Daily Scrum Sprint Review
Sprint Retrospective itedas Scrum Practitioner Open Base v syl3.x en01.00

Estimation and Velocity
Estimation Concepts Estimation the amount of work Velocity Estimation Methods itedas Scrum Practitioner Open Base v syl3.x en01.00

Estimation Concepts All Team Members
Development Team All Team Members The estimates should be based on the expertise of all members of the Development Team. use relative sizes As a rule, better estimation results are achieved in this way. focus on sufficient correctness / accuracy, not precision Relative Sizes: The height ratio between the individual buildings is 1:1,5:2 Accuracy (sufficient accuracy): How many km is it from Hamburg to Munich? 775 km according to Google Maps. It is not necessary to enter decimal places, since it will not change the estimation of the travel time. It is also in the nature of things that estimates are proven to have more or less large estimation errors. An example of what can be used in the seminar: Question 1: How many meters is the projector away from the right and left wall of the room? Question 2: Where is the projector located relative to the two walls? (Answer: About in the middle.) Commitment: In order to avoid including buffers, the estimates must not be used as the basis for any success measurement. The only purpose to be achieved is that the estimates improve over time. This can also be used to derive the fact that estimates are best made in story points, so that the environment is not able to judge the estimates or to mix it up ideal times and clear commited delivery dates. Estimates are not commitments Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Estimating the workload
The development team estimates workload for backlog entries. Estimations can be made in: ideal times (= Net working hours, without breaks and other interruptions) ideal hours or ideal days Story Points: relative units Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Time / relative size-based Estimation
Estimates are based on assumptions and contain uncertainties. Time-based estimates (based on elapsed time)... in person days (or person hours or similar) lead to unjustifiably high expectations regarding the completion date. therefore often include buffer times. mean an unnecessary liability because of the uncertainties they contain. differ significantly between experienced and inexperienced developers. are absolute sizes. Relative estimates (story points) … support cross-functional behavior. are more reliable in their predictive power. are self-correcting. are created faster and have a longer lifespan than time-based ones. are relative sizes. Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Ideal times: a problematic estimate
Specifying a time measure (= real time) results in the following problems: The given estimate indicate a precision they don’t have. It seems that the workload could be calculated exactly. Both result in unjustified expectations and unnecessary pressure in the development team. The way out: estimate in story points Story points are relative sizes To determination the size of a story you need: one (or more) reference (s) as fixed point (s) a unit (=Story Point) that describes the metric we use to measure a scale to indicate a quantitative gradation periodic redefinition of the reference Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Estimations: What? When?
Usual units of measurement Element Portfolio Backlog Product Backlog Sprint Backlog Task Backlog Units T-shirt sizes Story Points or Ideal Days Idealstunden/Aufwandsstunden Range XXS … M … XXL 1, 2, 4, 8, 16 … or 1, 2, 3, 5, 8, 13, 20, 40 … real number > 0 Verwendung Portfolio Planning Sprint Planning A B C Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Measuring scales for estimating
Estimates can only ever come close to the true values! Estimates are always subject to an estimation error! Number-based scales 2-power series: 1, 2, 4, 8, 16, 32, 64, 128 … 2k Based on the Fibonacci series of numbers: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 Other scales T-shirt sizes: XXS – XS – S – M – L – XL – XXL The Fibonacci sequence describes u. a. numerous growth processes of plants and animals. It seems like it is a kind of growth pattern in nature. [Quelle: Der goldene Schnitt, golden-section.eu, Dr. Dr. Ruben Stelzner in Zusammenarbeit mit Prof. Dr. Wolfgang Schad, abgerufen am 26. Oktober 2015]1 Note: If many smaller stories are processed in a sprint, the overall estimation error is smaller than if a few large stories are processed! Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Which story is potentially the best reference and why
The Reference Story Value Range: 1, 2, 3, 5, 8, 13, 20, 40, 100 Story A xxxx Business Value Story Points 1 Story B xxxx Business Value Story Points 20 None of the stories presented here is a good reference. One is too small, the other too large. A story of size in the midrange of the average story size would be good. Story C xxxx Business Value Story Points 40 Which story is potentially the best reference and why Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Affinity Estimation Triangulation Planning Poker
Estimation Methods Affinity Estimation Triangulation Planning Poker itedas Scrum Practitioner Open Base v syl3.x en01.00

Affinity Estimation quick estimation of a large number (> 20) of user stories Release planning or portfolio planning Preparation: List of user stories on post-its, sufficient space for grouping the stories Participants: Scrum team and, if necessary, other participants who can answer questions smaller larger 1 SP 3 SP 5 SP 8 SP 13 SP 20 SP Instead of each individual team member individually grouping stories, this can also be done by different teams in a scaled environment (scum-of-scrums). Syl_ID_6.1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Affinity Estimation: procedure
Silent Sizing: Sort quietly by relative size: Each member of the development team receives a set of stories. Stories that cannot be grouped through inquiries are put aside. (Time: approx minutes) Wikipedia-like Editing: Discussion of "questionable" placements in the development team and with the product owner in order to arrive at a coordinated placement of the stories in the development team. (Time: approx. 20–60 minutes) Place Stories into Sizing Buckets: Size assignment (clothing sizes, power of two or “Fibonacci numbers” etc.) to the individual story groups. (Time: approx. 10–30 minutes) Product Owner Review: The Development Team can now take a break while the product owner looks at the result to see if he has any questions for the team. (Time: 15 minutes) Wrap-up: The team answers the questions of the product owner and explains and / or revises his sizing decision. Documentation: The result is documented by the Product Owner. Syl_ID_6.1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Example of reference stories for two sizes to improve estimates
Triangulation So that estimates in individual sprints remain as comparable as possible, at least one reference story is required. 2 or more reference stories increase the estimation accuracy (= Triangulation) Example of reference stories for two sizes to improve estimates Syl_ID_6.1.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Planning Poker Each estimator receives a set of cards with one card value each. After a user story has been read out by the customer or product owner, it is briefly discussed in the team. Afterwards each appraiser evaluates the story for himself (!) And chooses a card. When each appraiser has made his assessment, the cards are revealed and the deviations are discussed. The rounds of estimates are repeated until the estimated values have sufficiently approximated. Schätzer Runde 1 Runde 2 Runde 3 Anita 3 5 Günther 8 Petra 20 10 Hannelore Syl_ID_6.1.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Estimation of the Teams Capacity
Person Working Hours / Day (h) Net Working Time 20 Day Sprint (h) gross net* Petra 8 4 80 Jutta 3 60 Hans Bertram 6 120 Gabi 5 100 Ursel Hans-Günther 2 40 total 580 * estimated average How does a team know how many user stories can be processed in the next sprint? Die Team-Kapazität in einem Idealzeitmaß abzuschätzen ist kein größeres Problem. Aber wie kommt das Team auf einen sinnvollen Sprint Backlog, der auf im Sprint mit hoher Wahrscheinlichkeit erfolgreich abgearbeitet werden kann? Syl_ID_6.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Identify development team capacity
The Sprint Puffer … serves to catch up with the unforeseen. can usually only be determined with increasing experience. maximum capacity other non-sprint commitments Editing the backlog elements in the sprint Sprint Buffer other sprint activities Planning, review, retrospective, product backlog maintenance Syl_ID_2.1.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Average of the last 2 sprints
The Velocity of a Scrum team indicates the amount of work that was completed in a sprint. serves two important purposes : It is the essential concept for Scrum planning. It provides a yardstick by which the Scrum team can assess and improve its use in delivering customer values. Average of the last 2 sprints Sprint Syl_ID_6.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Predict what can be done in the sprint
Situation 1: The team has already completed a few sprints and knows its velocity. Sprint 1 2 3 4 5 6 7 Story Points 20 70 80 100 120 110 mögliche Bandbreite für Schätzung 90%–110% Velocity Forecast for Sprint 2 = ca. 20 Story Points Velocity Forecast for Sprint 6 = ( ) / 4 = 93  83–102 Story Points Situation 2: The team is just starting a new task. Search for a first reference story with around 1–10 individual tasks and a processing time of approx. 0.5–5 days and assignment of a size of 1–10 story points. User stories should contain approximately 1 to 20 tasks. Each task should be completed in about 4 to 16 hours. A user story should be processed in about 0.5 to 10 days. Syl_ID_6.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Estimation ans Velocity
estimation concepts Estimating relative workload team capacity Velocity estimation methods itedas Scrum Practitioner Open Base v syl3.x en01.00

Steering Aspects Communication Monitoring Succession Planning
itedas Scrum Practitioner Open Base v syl3.x en01.00

Create an Agile Workspace Collocated, encourage
The Working Place The team should sit in a room, if possible, to support … face-to-face communication. osmotic communication. team discussions. Display important information (about the project and performance) in a clearly visible manner. The workplace should be flexible in order to enable an easy change between concentrated work and open discussions to discuss for concentrated work Agile flourishes when scrum team members work closely together in an environment that support the process. If at all possible the team should be collocated. Items listed in the slide are encouraged this way. Set up a dedicated area and remove distractions... Create an Agile Workspace Collocated, encourage Communicating face-to-face: Physically standing up Using simple communication tools Being aware of what others are working on: Getting clarifications from other team members Asking for help: Supporting others Big visible charts and Backlog Big white board to relax to inform itedas Scrum Practitioner Open Base v syl3.x en01.00

Development Team: Collaboration
Establishment of team rules to be observed such as punctuality etc. The product owner is not an enemy. Other teams should understand what we are doing and that we need them. We all work for the same goal. We know that everyone in the team does their best at all times so that we as a team are successful. Golden Rule communication rules Appreciation of the other I-messages address specific situation no blame Active listening solution orientation Information Radiator Task Board itedas Scrum Practitioner Open Base v syl3.x en01.00

Succession Planning Objective - Answer the question: How does the know-how stay in the team? Result: Securing the course of the project through … Increasing the Bus Factors to … prevent / decrease of bottlenecks due to vacation, illness etc. Methods / Aspects: pair programming maximum transparency better communication (stand-up meetings etc.) real co-ownership of the code Bus Factor Critical size that indicates how many team members can fail without the project coming to a standstill. Syl_ID_7.5 itedas Scrum Practitioner Open Base v syl3.x en01.00

Monitoring: Possible Key Figures
Predictability Burn Down Rate Velocity automatic tests Quality Sprint Goal Success Rate Errors Errors found in the test errors found by users (Escaped Defects) Technical Debt Information Radiator: KPIs (Key Performance Indicators) Value / benefits customer satisfaction Business Value Delivered Lean Throughput time Work in Progress Task Board Niko-niko calendar work ethic (Niko-niko calendar) Scrum Team Syl_ID_7 / Syl_ID_7.6 / Syl_ID_7.7 / Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Information Radiator: Important information at a glance
General expression for a representation of information that the Scrum team needs for self-control. simple / easy to understand current only visible as long as the topic is current should influence the team to change the undesired and to keep the desired clearly visible "less is more" Information Radiator: KPIs (Key Performance Indicators) Information Radiator: Simple: A chart or graph should not require minutes or hours of study. Ensure it is brief and concise. Anything dense or complicated will fail to communicate. Also, don't use highly derivative, biased, weighted information. Simple facts speak more profoundly than clever algorithms. Current: Any information that is not kept current is quickly ignored. Information more than a few days old is too stale to have evocative powers. Preferably: real time updates or end-of-day updates. Transient: Radiators that only expose problems shouldn't be up there long, otherwise it's clear that you aren't solving your problems. Once it's clear the team has gotten the message, and things are back on track, take down the info. Influential: A good information radiator influences the team's daily work. It may also influence managers, customers, developers, or other stakeholders. Highly visible: An effective information radiator needs to not only have information on it, but must transfer it to team members, stakeholders, and passers-by. Minimal in number: Having too many graphs or charts will cause all of the charts to lose evocative power. Also, exposing too many problems on the wall at one time can demoralize any team, so choose either the most important, timely, or fixable problem to highlight, and defer the rest. [based on Information Radiator at agileinaflash.blogspot.nl] ---- Quelle: :22: "Information radiator" is the generic term for any of a number of handwritten, drawn, printed or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on. Also Known As a related term, nearly synonymous, is "Big Visible Chart" more generally, one speaks of "informative workspaces" Expected Benefits Intensive use of information radiators conveys two messages in addition to the information itself: the team has nothing to hide from its visitors (customers, stakeholders...) the team has nothing to hide from itself: it acknowledges and confronts problems The main benefit of the practice is therefore to promote responsibility among the team members. A secondary benefit is that information radiators tend to provoke conversation when outsiders visit, which can yield useful ideas. Origins 1980s: the notion of "visual control" originating in the Toyota Production System is an anticipation of "information radiators" 1999: the term "Big Visible Chart" is coined by Kent Beck in "Extreme Programming Explained", though later attributed by Beck to Martin Fowler 2001: the term "information radiator" is coined by Alistair Cockburn ( , part of an extended metaphor which equates the movement of information with the dispersion of heat and gas Origin of the term : 1980: Toyota Production System „Visual Control“ 1999: „Big Visible Chart“ the book „Extreme Programming“ from Kent Beck 2001: „Information Radiator“ coined by Alistair Cockburn (American computer scientist) as part of a metaphor that equates the spread of information with the spread of gas and heat Syl_ID_7.7 itedas Scrum Practitioner Open Base v syl3.x en01.00

The Task Board Sprint Goal Stories Sprint Backlog Items Tasks To Do
The gate to the world Stories Sprint Backlog Items Tasks To Do Tasks In Progress Stories / Tasks Done 2 fix 1 fix 3 daily update Syl_ID_7.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Technical practices for implementing the task
shared code ownership programming standard Pair Programming … continuous code integration continuous refactoring itedas Scrum Practitioner Open Base v syl3.x en01.00

Sprint Goal Success Rate
Each sprint should (at least) provide a working product increment that meets the following requirements : fulfills the sprint goal corresponds to the Definition of Done (DoD), i.e. is developed, tested, integrated and documented © Kzenon - Fotolia.com Done Items Sprint Goal Success Rate = Sprint Backlog Items Syl_ID_7 itedas Scrum Practitioner Open Base v syl3.x en01.00

Small bugs - big meltdowns
A few wrong numbers or lines and it happens : Intel Pentium bug in floating point division: $ 400 million damage Converting 64-bit floating point numbers to 16-bit integers: explosion Ariane 5 (1996) "Dot" programmed instead of "comma": lost Venusonde Mariner 1 (1962) Source: :42 Pentium-Bug One of the most famous disasters in the computer industry was probably the Pentium Bug from Intel. The cost of this hardware problem was more than 400 million U.S. Dollar. From the Group's white paper on the problem, it can be seen that there are small errors in the floating point division for certain inputs. Intel has long claimed that there was no error and later admitted that the error occurred with one of 9 billion inputs, which did not prevent the semiconductor company from providing a replacement for the faulty chip. The problem was that the division algorithm used by Intel uses a look-up table with 1066 entries. Due to an error in a for loop, the transfer of the coefficients into the PLA (Programmable Logic Array) only resulted in the transfer of 1061 values, which leads to calculation inaccuracies of four decimal places for certain inputs. Such or similar errors have already caused problems in the past. The most serious computer glitch so far in medicine was in a medical radiation device for cancer, called Therac-25. As a result, there were several deaths in Canada due to excessive radiation doses. The reason for this was the lack of quality assurance by the software developers for the device. A more extensive simulation program would probably have been able to detect the errors early. During NASA's first Venus mission in 1962, a dot was incorrectly used instead of a comma in the FORTRAN code of Mariner 1, which caused the probe to crash. On the warship USS Yorktown in 1998, an input error caused a division by zero, which resulted in the ship floating around in the sea for hours without maneuvering. Ariane 5 Explosion The Ariane 5 explosion in 1996 brought a major setback to European space travel. The further development of Ariane 4 should secure European leadership in the space freight business. The economic damage here was more than 500 million U.S. Dollars because the new Ariane development had scientific satellites weighing two or three tons on board. An inconspicuous bug, which every computer science student must surely deal with in the first semester, caused a catastrophe here about 30 seconds after taking off. An investigative committee soon found that a conversion error led to the explosion. The control of the rocket was taken over by an on-board computer. Some time after the start, the so-called inertial control system began to send confused data to the on-board computer. The system actually delivered 64-bit floating point numbers for horizontal rocket acceleration in relation to the launch platform. In the meantime, however, the on-board computer only received error messages from the inertial control, with which it could not do anything and switched off the system. The reason for this was that a small subroutine of the inertia control tried to convert 64-bit floating point numbers into 16-bit integers, which are known to store numbers less than plus sign. This happened because the rocket engineers thought that the integer limit could not be reached during these operations. This was probably correct in the days of Ariane 4, but the newly developed Ariane 5 was faster. A fraction of a second after the inertial control was switched off, a redundant system started operating. This also failed because the installed software was identical to that of the main system. Finally, the automatic self-destruction of the rocket was initiated because the pressure on the boosters became so great due to the lack of course corrections that they threatened to break off. Numerical calculation errors are often the cause of devastating accidents. It was not only the Ariana mission that found its premature. During the first Gulf War in 1991, an American anti-aircraft missile went off course due to inaccurate calculations and hit a U.S. Camp. 28 soldiers were killed in the accident. There was an embarrassing hour for NASA when it became known why it lost the Mars Climate Orbiter: an involved development team used the metric units common in science, with another team using English units (such as inches). The incompatibility ultimately led to the loss of the probe. The operation cost NASA about 125 million US dollars. „cm” instead of “inches ”: missile misses target (Gulf War 1991) Syl_ID_7 itedas Scrum Practitioner Open Base v syl3.x en01.00

Escaped Defects cause great costs: approx. € 84.4 billion * are the annual losses due to software errors in medium-sized and large companies. Undetected bugs are found by the user (=> measure of the quality delivered). Planning Analyse Design Coding Testing In Service Costs * Quelle: Zahlen aus dem Jahr 2006 Syl_ID_7 / Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Escaped Defects Chart Sprint
Syl_ID_7 / Syl_ID_9.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Testing in the end doesn't work because
Feedback that should be responded to comes very late. the same mistakes are made over and over again without being recognized. the project status (due to the undetected errors) can hardly be determined. the time for sufficient testing is rather sacrificed to the go-live appointment. it is difficult to improve the quality of a finished product afterwards. itedas Scrum Practitioner Open Base v syl3.x en01.00

Technical Debt „ When you deliver code for the first time, it's like getting into debt. A few small debts accelerate development, as long as they are repaid on time with a revision ... It becomes dangerous if the debt is not repaid …“ Ward Cunningham 1992 Technical Debt describes all the drawbacks, deficits and defects of the software such as: inappropriate design Defective and known problems insufficient test coverage excessive manual testing when automatic tests are available poor integration and release management lack of platform experience (lack of COBOL knowledge ) … Syl_ID_9.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

The consequences of Technical Debt
declining customer satisfaction large number of defects rising development and support costs Declining Performance (declining Velocity) Reason: Since the debt has to be reduced in the form of bug fixes, more and more resources have to be used for this as the debt increases. Syl_ID_9.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Technical Debt: Reasons
Pressure to hold deadlines unsuccessful attempts to increase velocity Reduction of the test scope Accumulation of debt About the graphic: The release backlog is the same size for release 1 and 2. When processing the backlog for Release 1, it branches out that, given the possible development speed, it is not possible that the release will not be ready on the desired date (business specification). This results in a deadline pressure that leads to the accumulation of technical debts (due to a lack of testing, sloppy work, etc.). Due to the necessary bug fixes for release 1, the processing rate of the backlog for release 2 drops. A renewed deadline pressure results in an increase in technical debts. Release-Backlog Sprint 1 … n Sprint n+1 … m Syl_ID_9.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Umgang mit technischen Schulden
Technische Schulden müssen organisiert werden! Verwalten und überwachen Einsatz von bewährten Techniken wie: einfaches Design Test-Driven Development kontinuierliche Integration automatisiertes Testen Refactoring … starke Definition of Done Verstehen der wirtschaftlichen Aspekte Sichtbar machen geschäftliche Ebene technische Ebene (Technical Debt Backlog) Abbauen nur die lohnenswerten die, die man bei der Arbeit an neuen Inkrementen gerade findet Ticketing-Tool (Incidents, Problems, Changes) Technical Debt Backlog Product Backlog Syl_ID_9.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Information Radiator: Delivered Story Points
Syl_ID_7.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Sprint Burn-down Chart
30 Story Points 25 20 15 10 5 1 2 3 4 5 6 7 8 9 10 Days Syl_ID_7.1 / Syl_ID_7.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Release Burn-down Chart
300 Story Points 250 200 150 100 50 1 2 3 4 5 6 7 8 9 10 11 Sprints Syl_ID_7.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Burn-down Bar Chart Product Backlog - 50 Points 300 Story Points
Velocity = 300 Points/7 Sprints = 43 Points/Sprint Backlog = 50 Points 250 200 + 100 Points 150 100 300 Points 50 Burn-down bars can show the changes in the Product Backlog better than normal burn-down charts. Completion of the items will be applied to the top of the bars and adding or removing items in the Product Backlog will be reflected to the bottom of the bars. Product Backlog 1 2 3 4 5 6 7 8 9 10 11 Sprints -50 -100 Syl_ID_7.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Burn-up Chart Product Backlog 400 350 - 50 Points
Velocity = 300 Points/7 Sprints = 43 Points/Sprint Backlog = 50 Points 300 Story Points 250 200 + 100 Points 150 100 300 Points 50 Product Backlog 1 2 3 4 5 6 7 8 9 10 11 Sprints Syl_ID_7.1 / Syl_ID_7.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Business Value Chart It’s a good idea to monitor the amount of business value created in each Sprint. It usually goes down, and it’s a good idea to stop the project when the output is not valuable enough. Syl_ID_7.1 itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Scrum Control Aspects
The workplace The communication Succession planning The monitoring itedas Scrum Practitioner Open Base v syl3.x en01.00

Scaling Scrum Vertical / horizontal Scaling
Working in complex / large Project Release Train itedas Scrum Practitioner Open Base v syl3.x en01.00

Vertical and horizontal Scaling
Forming of further Scrum Teams to develop various products Vertical Scaling Vertical scaling means building additional development teams in order to be able to develop more complex / extensive products. Horizontal scaling means building additional Scrum teams to be able to develop different products. Horizontal scaling is particularly about harmonizing the understanding and procedure across all Scrum teams sufficiently to, among other things, to be able to have the team members work on individual projects without major friction losses depending on requirements. Vertical Scaling Forming of further Development Teams in order to be able to develop a complex product Syl_ID_8.3 itedas Scrum Practitioner Open Base v syl3.x en01.00

Vertical Scaling: Form new development teams
Vollständig neues Team Grow-and-Split-Model Split-and-Seed-Model Completely new teams Requirements: The organization has a high degree of maturity ("is mature") in the application of agile concepts. Problem: The new teams are unfamiliar with the subject and are therefore more inefficient at the beginning. Grow-and-split model Refill the original team with new members to the maximum. After know-how transfer divided into two teams. Useful to use when transitioning from a pilot project to a productive project Benefits: The original team remains. The existing knowledge will be brought into all new teams. Team development runs with fewer problems. Disadvantage: Time consuming (if more than 2 teams are to be formed) Split-and-Seed model Division of the first team into the required number of teams and replenishment of the new teams with resources Advantage: The original team no longer exists. Team building effort Syl_ID_8.3 / Syl_ID_10.3 / Syl_ID_10.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Working in complex / large projects
Product 1 Product 1 Product Owner (if necessary, for individual modules) 1 Product Backlog M Scrum Master (one per team or one for multiple teams) N Development Teams Ort A DoR DoD Ort B The Definition of Ready (DoR) and Definition of Done (DoD) must match as far as is reasonable for all teams so that the quality of the product can be guaranteed. Note: the color coding (red, yellow, green) runs through the next slides and explains certain topics of collaboration / team coordination. Syl_ID_8.1 / Syl_ID_8.2 itedas Scrum Practitioner Open Base v syl3.x de01.00

Scrum of Scrums: Cross-team coordination
Questions to be answered by each representative of the development team : What has my team done since the last meeting that could affect the other teams? What will my team do before the next meeting that could affect the other teams? What problems of my team could the other teams help with? Scrum of Scrums serves for cross-team coordination takes place a few times a week if necessary is limited to 15 minutes (=> coordination) As with the Daily Scrum, problem solving can take place immediately Syl_ID_8.1 itedas Scrum Practitioner Open Base v syl3.x de01.00

Release Train: Cross-team coordination
Sprints Sprints Release Planning Inspect & Adapt Release Planning Inspect & Adapt All sprints are the same length. When planning the release, all (!!) team members come together (=> a very large room may be required) Syl_ID_8.2 itedas Scrum Practitioner Open Base v syl3.x de01.00

Release Train: Rules Planning and release dates take place frequently and regularly. Dates and quality are fixed, the scope is variable. Intermediate global and objective milestones are established. All teams work with the same sprint duration. Continuous integration is implemented at the top or system level as well as at the functional and component levels. The release increments are available at regular intervals (eg: every 3 or 6 sprints) for preview ("Review"). Special sprints can be used to reduce technical debt. In order for teams to build on similar constructs, corresponding preparatory work is necessary. Syl_ID_8.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Distributed teams virtual collaboration (tools!)
coordinated working hours (especially in different time zones) Face-to-face communication at key points like Kick-off meeting Planning phase; especially release planning Team HH Team M Core Hours are the hours when everyone can commit to being in the (virtual) team space. In this example there are only 1.5 ‘core hours’ in the afternoon (3 PM - 4:30). A core schedule helps to set a sense of balance and cohesiveness. One of the biggest challenges to overcome when implementing Scrum within a distributed team environment is that of communication. As you may be aware, within a formal Scrum environment, everyday person-to-person conversation is a valued part of the process. Consequently, it is important to have that face-to-face time during vital points in the project - such as the beginning, planning phase of the project. Release Planning should be collocated. At this time, all of the team members can get acquainted with one another. As a result of working directly with one another, a sense of cohesiveness can develop. itedas Scrum Practitioner Open Base v syl3.x en01.00

Frameworks for scaling Scrum
When several Scrum teams create an integrated increment together, Nexus is the exoskeleton that rests on the teams. Nexus is consistent with Scrum, and its parts will be familiar to those who have worked with Scrum on projects. Download: The Scaled Agile Framework combines approaches from the agile methods Scrum, Kanban and Extreme Programming with Lean Thinking as well as the principles for Lean Product Development formulated by Donald Reinertsen and thus enables agility to be applied in the enterprise environment and on a large scale. Download: Syl_ID_8.4 itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Scaling Scrum
Vertical / horizontal scaling Form new development teams Working in complex / large projects Release train Distributed teams Frameworks for scaling Scrum itedas Scrum Practitioner Open Base v syl3.x en01.00

Introducing Scrum Fundamental Approach
Enterprise Transition Community (ETC) Reaction to Changes Introducing Agile Practices Coaching itedas Scrum Practitioner Open Base v syl3.x en01.00

Benefit from agility and scrum
Business benefits more benefits in less time agile change management, driven by business and market for the benefit of the customer faster market launch (time-to-market reduction) People Self-organizing, cross-functional teams with decision-making powers are more motivated and bring better results in less time. Processes lean processes without unnecessary overhead Reduction of waste in the sense of lean management higher quality itedas Scrum Practitioner Open Base v syl3.x en01.00

On the way to an agile company
experimental phase Acceptance phase culture shock adjustments (Organization, Method) Guidelines and documentation In Service Non-agile organization agile Organization Pilot Adaption Use Scope and Objectives: selected departments Low risk projects learn how agile could work in the organization Scope and Objectives: selected full area all projects complete mutual adjustment of method and organization Presentation of company-wide guidelines, documents and tools Inspect & Adapt Inspect & Adapt Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Basic procedure for the introduction
Scrum should be introduced as part of an agile project approach. Pilot Train the team Coaching by an experienced Scrum Master Clarification and distribution of roles Start with a first project with first positive results (quick wins, low hanging fruits) Step by step: adapting and changing the organizational and project culture Beware of Water fallacies and Agile Phobias Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Enterprise Transition Community (ETC)
Scrum team that carries out the transition to an agile approach in a company This team works according to Scrum but does not produce any software. It delivers organizational changes in small increments per sprint. Inspect & Adapt Inspect & Adapt Awareness Awareness that the current approach (processes) is delivering unacceptable results Desire The desire to solve current problems with Scrum Ability The ability to be successful with Scrum Promotion Promote Scrum by sharing experiences so everyone can see our success Transfer Transfer of the application possibilities of Scrum to all areas of the company Syl_ID_10.1 / Syl_ID_10.2 itedas Scrum Practitioner Open Base v syl3.x en01.00

Responding to changes 2. Denial 7. Integration 3. rational insight
5. Learning Quelle :05: 6. Understanding 1. Shock perceived own competence 4. emotional acceptance See also Kübler-Ross-Model Zeit Syl_ID_10.5 itedas Scrum Practitioner Open Base v syl3.x en01.00

Introduce agile practices
Collective Code Ownership Pair programming Test-Driven Development agile software configuration management (SCM) Continuous Integration Continuous Refactoring Sustainable Pace Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Collective Code Ownership
Nobody is the “owner” of a piece of code. The entire development team is responsible. Anyone can change any code. it follows : Strengthening teamwork Focus on the product better code quality (intelligibility, "from a single source“) 'get all text from current slide allText = titleLine For Each textShape In s.Shapes If textShape.HasTextFrame Then allText = textShape.TextFrame.TextRange If InStr(1, textShape.TextFrame.TextRange, Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

„Watch-the-Master“ phenomenon
Pair Programming Two developers work together on the code (one screen, one keyboard). The solution is discussed and designed together. Variant: If you have an idea, hand in the keyboard. leads to fewer errors and higher quality (4-eyes principle) promotes team building (and by changing pairs the "Collective Code Ownership") increases motivation supports learning important for: Successor planning ("bus factor") Problem: „Watch-the-Master“ phenomenon A potentially occurring effect that only one works, the other just watches and NO knowledge transfer takes place. Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Test-Driven Development (TDD)
TDD approach: Programming is done in micro iterations TDD is NOT a test process, but a development method Understanding the test promotes understanding of the function to be created continuous testing and improvement high degree of automation and test coverage Involvement of the customer Start Write test! Write / change the program code until the test is passed! Clean up the code (Refactoring)! End Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Software Configuration Management (SCM)
Objectives Ensuring the integrity of a product Recognize and master changes Code Repository Developer A Developer B X Code consolidated Code changed Code locked Code not locked Check- out Check- in Check-in Software configuration management (SCM) is known as a method of bringing control to the software development process, and thus, proper application of SCM is a key component in the development of quality software. FDD and DSDM take software configuration management explicitly into account. In FDD, SCM is one of the method's "best practices" that among others needs to be included in order to obtain the greatest benefit from the method. XP's approach to SCM can be seen as implicit. The method does not require software configuration management to be conducted. However, there is a practice in XP depicted on the next slide that can be considered good practice. In Scrum it is not explicitly addressed. Recommendation: Check in at the end of every day! Take problems seriously and treat them as a team! Consolidate as often as possible! Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Continual Code Integration
Objectives continuous increase in software quality permanent availability of an operational stand for demo, test or sales purposes Approach Code changes are adopted as early and simply as possible in the code base. Generation, testing and deployment are largely automated. Fast and easy provision of new program versions e.g. B. by "nightly builds“. Benefit Integration problems are constantly being discovered and resolved - not just shortly before a milestone. Incompatibilities are recognized early and can be remedied promptly. The system's immediate reaction to checking in a faulty or incomplete code “educates” the developers in a positive sense to be more responsible and shorter check-in intervals. Recommendation: at least daily. Low merge effort, since the longer you wait with the integration, the greater the merge effort. Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Continual Refactoring
Refactoring is about improving the non-functional properties of the code, i.e. the internal structure and properties without changing function or external behavior. Refactoring Increase legibility Reduction of complexity Improve maintainability Improvement of the expandability Continually improve! The sooner the better! Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility. Typically, refactoring applies a series of standardized basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behavior of the software, or at least does not modify its conformance to functional requirements. Many development environments provide automated support for performing the mechanical aspects of these basic refactorings. There are two general categories of benefits to the activity of refactoring. Maintainability. It is easier to fix bugs because the source code is easy to read and the intent of its author is easy to grasp Extensibility. It is easier to extend the capabilities of the application if it uses recognizable design patterns, and it provides some flexibility where none before may have existed. Extensibility is a software design principle defined as a system’s ability to have new functionality extended, in which the system’s internal structure and data flow are minimally or not affected, particularly that recompiling or changing the original source code is unnecessary when changing a system’s behavior, either by the creator or other programmers Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Sustainable Pace The pace of development should level off at a sustainable level. Assuming stable teams and comparable tasks … the team can keep the development speed for a long time without being overwhelmed (e.g. goal achievement without overtime). the development speed is stable  easy to plan. it is guaranteed that all processes are established and run smoothly. productivity is at a high level (better than before / during the introduction of agile methods). Sustainable Pace prevents team overload Syl_ID_10 itedas Scrum Practitioner Open Base v syl3.x en01.00

Meet the team where it is
Coaching Objectives Meet the team where it is Training Coaching self-sufficient implementation Clarify the goals of the organization Team motivation Determination of the (first) training need Train the Team (Basics and role-specific training) Team Building Team spirit, communication and motivation the ability for constructive discussion working climate Productivity (efficiency and effectiveness) team roles Support during implementation and practice (communication, constructive discussion, working atmosphere, team roles), problem and conflict solutions Anticipated resistance to change Conservers 25% prefer changes without structural changes want security / predictability honor traditions and established practices Pragmatists 50% prefer practical changes are open to both sides of an argument more focused on results than on structures Originators 25% prefer changes that question current structures challenge accepted assumptions take little account of accepted agreements Syl_ID_10.5 itedas Scrum Practitioner Open Base v syl3.x en01.00

Team Dynamic Performing Norming Storming Forming
Characterized by work orientation, flexibility, openness of the team members, solidarity, performance orientation and goal-oriented action of the team. The manager only specifies global goals (visions) and requires little energy, since the team largely controls itself. The Scrum Master ensures that the standards are maintained. Norming Characterized by the development of new group standards and new manners, by feedback and exchange between the team members and a "we" orientation.  The Scrum Master coordinates the development. Storming Characterized by subliminal conflicts, a self-portrayal of the (new) team members, struggle for (informal) leadership, "I" orientation and clique formation.  The Scrum Master leaves room and objectifies discussions. Note: As part of the dissolution of a team, the last follows the adjourning phase Forming Characterized by courtesy, careful palpation, the pursuit of security and getting to know each other.  The Scrum Master leads and sets priorities. itedas Scrum Practitioner Open Base v syl3.x en01.00

Team problems Signs of problems Rumors appear
the flow of communication is decreasing Tasks stay put negative emotions increase more sick leave unpunctuality longer decision-making processes cliques Approach of Resolution All parties must be interested in resolving a conflict. Everyone represents their point of view. Similarities are explored. Everyone stays fair. Everyone is ready to compromise. Everyone makes proposals for solutions. itedas Scrum Practitioner Open Base v syl3.x en01.00

Trouble – Problem – Conflict
Resolution Appropriate approach unreasonable Appropriate approach unreasonable Trouble Everyday obstacles resource issues quality problems … Example: Recurring printer failure. At times, users cannot print. Workaround: After restarting the printer, it works again for a certain time. But the printer actually needs the current firmware for its LAN interface in order to eliminate the error permanently. Problem Obstacles that seem impossible to solve lack of powers lack of support … Example: Nobody takes care of the procurement and installation of the current firmware. The users are annoyed. Conflict Intentions that cannot be realized Example: The update of the printer is always postponed due to different priorities. Users consider the support to be incompetent. itedas Scrum Practitioner Open Base v syl3.x en01.00

Root Cause Analysis Identify topic and situation and examine for cause
The following causes can be distinguished : Conflict of fact: based on a lack of information or misinformation Conflict of interest: is based on subjectively or objectively different interests between stakeholders Conflict of values: is based on a different appreciation of a situation Relationship conflict: is based on (strong) negative emotions between stakeholders ("They cannot work together.") Structural conflict: is based on unequal power and authority relationships Mixed causes of conflict: With mixed causes, all causes should be identified so that a suitable resolution strategy can be selected. itedas Scrum Practitioner Open Base v syl3.x en01.00

Summary: Introducing Scrum
Benefit from agility and scrum Basic procedure Enterprise transition community (ETC) Responding to changes Introduce agile practices coaching team dynamics Team problems itedas Scrum Practitioner Open Base v syl3.x en01.00

itedas Certified Scrum Practitioner Open Base Slide Deck

Similar presentations

Presentation on theme: "itedas Certified Scrum Practitioner Open Base Slide Deck"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

itedas Certified Scrum Practitioner Open Base Slide Deck

Similar presentations

Presentation on theme: "itedas Certified Scrum Practitioner Open Base Slide Deck"— Presentation transcript:

Similar presentations

About project

Feedback