Scrum Basics

1. Scrum Basics Presented by Juan Banda

2. Problems in Software Industry Releases take too long Stabilization takes too long Changes are hard to make Quality is falling Death marches are hurting morale People are not communicating well

3. Roots of Scrum Lean Knowledge Management by Nonaka & Takeuchi Built-in instability Self-organizing project teams Overlapping development phases “Multilearning” Subtle control Organizational transfer of learning

4. Make your own path There is no fixed and patented Agile process, only Principles and Values Principles and Values are not something fixed, they can guide but not dictate how things should be Rules are rigid, Principles and Values are flexible like Agile

5. Scrum is a framework The framework set the basic rules that a team uses to play a game Each team has its own style A team needs to constantly reinvent itself

6. Scrum comes handy It will help you to build better software in shorter releases cycles and with more quality associated Scrum is an empirical process; not a formal, rigid and out of the box one Like a Swiss Army tool, Scrum is nice, shiny, easy to use, made for last, adaptable and not expensive

7. Scrum four pillars Scrum rests on four legs of iterative development that generates increments of functionality using self-organizing teams that are cross-functional

8. Scrum flow This flow defines the different artifacts and ceremonies within the Scrum framework One important consideration is that the flow is based on an incremental and iterative process

9. Product backlog The Product Backlog contains a prioritized list of items – user stories that will be developed by the team during the sprint, the current and the next release The Product Backlog is not static; it increases when new requirements arrive and decreases when user stories have been completed

10. Sprint backlog The Sprint Backlog is the list of user stories that the teams commits to work in an sprint This list comes from the Product Backlog and should be changed without the team consensus and the Product Owner’s approval

11. Burn down charts The Burn Down char is not exactly a monitoring tool that shows productivity On the contrary, this chart could be used as a predictive tool for planning next sprints It’s key that the Scrum Master and the team keep this chart updated and know its meaning

12. Scrum roles & responsibilities

13. Chickens & pigs These guys are fully committed These are not

14. Team Responsibilities Estimating size of backlog items Committing to increments of deliverable software – and delivering it Tracks own progress Is self-organizing – but accountable to the Product Owner for delivering as promised Improving constantly its own processes

15. Basic truths about team motivation People are most productive when they manage themselves People take their commitment more seriously than other people’s commitment for them People have many creative moments during down time People always do the best they can Under pressure to “work harder” developers automatically and increasingly reduce quality

16. Basic truths about team performance Teams and people do their best work when they aren’t interrupted Teams improve most when they solve their own problems Broad-band, fact-to-face communications is the most productive way for teams to work together

17. Basic truths about team composition Teams are more productive than the same number of individuals The optimum size team is around seven people, and no more than nine Products are more robust when a team has all of the cross-functional skills (development + QE) focused on the work Changes in team composition often lower productivity for a time

18. Scrum Master Responsibilities Empowering and shepherding the team Removing impediments Keeping the process moving Socializing Scrum to the greater organization

19. Additional resources • Scrum Bolivia LinkedIn user group • http://www.linkedin.com/groups?gid=2229883&goback=.gmp_2229883.gde_2229883_member_72362318.anp_2229883_1317385874382_1

20. Thanks for attending