Agile Development Focus on Scrum Notes by PZ

Agile Development Focus on Scrum Notes by PZ based upon Scrum Guide and research from different authors who have worked with SCRUM

Agenda Project management Warm up What is Agile Scrum Sprint Roles Artifacts ceremonies

requirements Complexity Chang e engin e product Project work concept service Change statet

Project characteristics ►A clearly defined goal ►A date when it must be completed ►Unknown factors and risks ►Limits on cost and resource consumption ►New experiences ►Challenges to thinking in grooves ►Interdisciplinary cooperation A project is a goal-directed enterprise involving the integrated deployment of people to achieve success

Project Management Mindmap procure external goods and services with the aim of fulfilling project scope ensure the various elements of the project are coordinated appropriately to ensure that the project includes and contains all the work that is needed identify, analyse and obviate project risks ensure prompt project close out ensure procurement, collection, management, storage and definitive distribution of the project ensure the project is completed within the approved budget ensure the most efficient use of the people involved ensure that the project fulfils the needs it was implemented to fulfil

Elements of a project The 9 knowledge areas

Warm up

Warm up for the ”real thing” How the customer explained it

Warm up for the ”real thing” How the customer explained it How the project leader understood it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it What the beta testers received

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it What the beta testers received How business consultant described it

Warm up for the ”real thing” How the customer explained it How the project was documented How the project leader understood it How the analyst designed it How the programmer wrote it What the beta testers received How business consultant described it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the project was documented What operations installed How the analyst designed it How the programmer wrote it What the beta testers received How business consultant described it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the project was documented What operations installed How the customer was billed How the programmer wrote it What the beta testers received How business consultant described it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it How the project was documented What operations installed How the customer was billed How it was supported What the beta testers received How business consultant described it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it What the beta testers received How the project was documented What operations installed How the customer was billed How it was supported What marketing advertised How business consultant described it

Warm up for the ”real thing” How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it What the beta testers received How business consultant described it How the project was documented What operations installed How the customer was billed How it was supported What marketing advertised What the customer really needed

visions present visions System Development Perform (product) reflection Change design analyse implementation transverse Productoriented Management (proces) planning estimation regulation Decision, kommunication, socialising Processor iented

Exercise Airplane Factory, Scrum Exercise The concept of this activity is for teams to use scrum tactics and Agile methods in order to create an assembly line of paper airplanes. The team that is able to create the most airplanes (they must similar) within the time constraints is crowned the winner. Below are the requirements of the contest. • The aircrafts should be released by Sprints (3 Sprints with 3 minutes each); • The teams had 3 minutes to discuss the process (planning and retrospective meetings); • Each team should estimate how many aircrafts they could release in each Sprint; • They should not stock material nor aircrafts; • The aircraft should have 12 window • One cabin • The logo of the corresponding company (team’s name) • A door • and of course, the airplane should be able fly! Each team must consist of a Scrum Master (Which Should be known by the whole team), In the end of each Sprint, the teams could plan the next sprint, with new estimates, according to the knowledge that were acquiring during the old releases .

Scrum overview Scrum is a framework for organizing and managing work Not following standardized process of following a series of sequential steps Based upon a set of Values (FROCC) Pricipels (what is the ideas in scrum) Practices (how to do) That provide the foundation (like the foundation of a building) to which you or your organization will add relevant professionel elements The result will be a version of scrum that is uniquely yours

Agile Manifesto

Agile principles Source: Scaling Software Agility – Best Practices for Large Enterprises by Dean Leffingwell Welcome change Our project is constantly changing Optimize the project around that environment Working software is the primary measure of progress Nothing is complete until we have working software “Just Enough” Process and Artifacts Sufficient to achieve iteration goals and readily maintain the results Self-Organizing Teams The team actively participates in managing the iteration Teams develop low level plans to achieve iteration goals Knowledge transfer via conversation. . . Is the most effective communication method, written words / Models leave too much open to interpretation

SCRUM values

Courage It takes courage to call out problems, identify impediments, ask for help, receive help, and offer help. It also takes courage to make decisions and to say no

Focus is the concentration of attention. When you focus – you can learn, dig deeper and understand be

commitment This value is about conscious commitment – making a promise together and doing everything we can to keep it. It means "to carry into action deliberately” or, as Yoda says, "Do, or do not. There os no try

respect Requires respectful interactions. On a practical level respect includes taking someone's feelings, needs, thoughts, ideas, wishes and preferences into consideration. It means taking all of these seriously and giving them worth and value. It also includes acknowledging them, listening to them, being truthful with them, and accepting their individuality and idiosyncrasies

Openness is characterized by an attitude of ready accessibility; without concealment; not secretive. A high level of 'transparency’

“The only constant is change”

SCRUM definitions Scrum is an agile Process that allows us to focus on delivering the highest business value in the shortest time. (Mike Cohn, Mountain Goat Software) Scrum is an iterative, incremental framework for project management and agile development. (Wikipedia). Scrum is a Framework that let us create Software/products focused in both business needs and business changes in the shortest period of time

Scrum overview

Sprints Scrum projects make progress in a series of “sprints” Analogous to Extreme Programming iterations and Kanban Typical duration is 2– 4 weeks or a calendar month. Could also be less A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint

Sprint Process

Sequential vs. overlapping development Requirements Design Code Test Rather than doing all of one thing at a time. . . Scrum teams do a little of everything all the time Source: “The New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Role playing game! 1. On 3 A 3 papers write the 3 scrum roles 2. The team members divide the task tiles among each other so the have the same number each 3. Place appropriate tasks on different scrum roles in silence (no team discussion) 4. The whole team discuss and try to agree about the tile placement 5. Check another groups work and discuss some of the differences 6. Discuss in plenum why there are differences (different way of thinking in the roles, depneding on the organization, depending the type of project etc

No changes during a sprint Change Plan sprint durations around how long you can commit to keeping change out of the sprint

Tools Task board Software Tools

Scrum exercise Which are Roles, Activities or artifacts? Sprint retrospective Product owner Product backlog Scrum master Portentially shippable product increment Sprint execution Sprint review Sprint Development team Product backlog grooming Sprint planning Daily scrum Sprint backlog

Scrum Scenario

Scrum Framework Roles Artifacts Ceremonies Product Owner Product backlog Sprint Planning Sprint Review Scrum Master Sprint Backlog Team Burn Down Charts Sprint Retrospective Daily Scrum Meeting

Product Owner Define the features of the product Product Backlog owner Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results He cancel an Sprint.

Scrum Master Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences A Scrum Master should never be the Product owner

Team Typically 7 people (+/- 2) Cross-functional team: Teams are self-organizing Membership should change only between sprints Turns the product backlog into increments of potentially shippable functionality Show the deliverables to the product owner

Pigs and Chickens Product Owner Scrum Master Team Members Users Managers Marketing

Scrum Framework Roles Artifacts Ceremonies Product Owner Product backlog Sprint Planning Sprint Review Scrum Master Sprint Backlog Team Burn Down Chart Sprint Retrospective Daily Scrum Meeting

Product Backlog Is the list of requirements Is dynamic and in constantly evolution. (alive document) Prioritized by the product owner Risk, value, and necessity. Reprioritized at the start of each sprint. Product Backlogs items are usually stated as user stories. Should take around 10% of each sprint to review the product backlog.

Product Backlog Sample Backlog item Estimate Allow a guest to make a reservation As a guest, I want to cancel a reservation. As a guest, I want to change the dates of a reservation. As a hotel employee, I can run Rev. PAR reports (revenue-per-available-room) Improve exception handling. . . 4/13/2011 58. . . 3 5 3 8 8 30 50

Sprint Backlog Consists of the tasks the Team performs to turn Product Backlog items into a “done” increment. It is developed during the Sprint Planning Meeting. It is all of the work that the Team identifies as necessary to meet the Sprint goal. One day or less (2, 4, 6 or 8 hour) is a usual size for a Sprint Backlog item that is being worked on. Only the Team can change its Sprint Backlog during a Sprint

The sprint Goal A short statement of what the work will be focused on during the sprint User research Make the user research and Database Application specify the requirements Make the application run on SQL Server in addition to Idea development Oracle. Generate possible ideas for the concept using new 60 technologies

Sprint Backlog sample Tasks Mon Tues Wed Thur Fri 8 4 8 Code the middle tier 16 12 10 4 Test the middle tier 8 16 16 11 8 8 8 4 Code the user interface Write online help Write the food class Add error logging 12 8

Sprint Burndown Chart Is a graph of the amount of Sprint Backlog work remaining in a Sprint across time in the Sprint

Scrum Framework Roles Artifacts Ceremonies Product Owner Product backlog Sprint Planning Scrum Master Sprint Backlog Daily Scrum Meeting Sprint Review Team Burn Down Charts Sprint Retrospective

Team capacity Product backlog Business condition s Current product Technology Sprint planning meeting It is time-boxed to eight hours for a one month Sprint prioritization • • Analyze and evaluate product backlog Select sprint goal Sprint planning • • • Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint backlog

Planning Returns Coupons Returns Gift vouchers Coupons Sprint backlog Sprint goal Team selects items from the product backlog they can commit to completing Sprint backlog is created Payments Prioritized Product backlog Tasks are identified and each is estimated (1 -8 hours) Collaboratively, not done alone by the Scrum. Master High-level design is considered

Planning ases Test c 3 s hour e Servic s classe Returns Sprint backlog UI JSP G 2 s hour l Visua n Desig 4 s hour rs 2 hou Tasks Team builds Code the UI 2 hours Coupons DAO + DBUnit 1 hours Database design Service + JUnit 1 hours

Tools

Daily Scrum User story Max. 15 minutes Stand-up Not for problem solving

Daily Scrum Meeting 3 questions 1 2 3 • What did you do, since last daily meeting? • What will you do today? • Is there a roadblock on your way? Scrum tus for the re not sta These a front of r Maste commitments in They are peers

Sprint Review Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2 -hour prep time rule No slides Whole team participates Invite the world

Sprint Retrospective After the Sprint Review and prior to the next Sprint Planning meeting This is a three hour, time-boxed meeting for monthly Sprints At this meeting, the Scrum Master encourages the Scrum Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint

Sprint Retrospective • Whole team gathers and discusses what they’d like to: Start doing Stop doing Continue doing

Definition of “Done” Avoid the 90% syndrome Coded, commented, checked in, integrated, reviewed, unit tested, deployed to test environment, passed user acceptance test & documented. . . = DONE

links www. agilenutshell. com/ intersting walk through http: //www. scrumwise. com/ good tool http: //www. scrumdesk. com/ scrum tool http: //www. scrumexpert. com/tools/usingcommercial-scrum-tools-for-free/ overview of a lot of scrum tools incl Kanban